Посмотрел вот этот вот классный доклад и снова убедился, что разработка сплошь и рядом состоит из трейдофов, на которые постоянно приходится идти – https://youtu.be/wi6h9ox1wwM?si=lMNIw2G7J8g4X2s6

Серебряной пули как всегда нет, а даже дефолтные проверенные решения таят много опасностей.

Например, обычная limit-offset (paging) пагинация очень непроизводительна. Дело в том, что select(Model).order_by(Model.field).offset(10).limit(10) внутри БД не берет "10 записей" магическим образом, а получают всю выборку со страницы, фильтрует ее, сортирует, а потом итерируется с первой записи полученной подвыборки до позиции offset. И только после чего берет limit записей. Как вы понимаете, такое поведение на больших данных оооочень медленное. И это совсем не то, что мы ожидаем.

Как решение придумали Keyset пагинацию. Суть очень простая – мы прям с фронта передаем индекс последней записи, откуда выдавать новую порцию select(Model).where(Model.id > last_id).limit(10). Но такую пагинацию уже надо готовить с учетом специфики ваших данных, типовых запросов к приложению и тд. Как минимум без правильно сваренных индексов ее не реализуешь. Но работает она действительно быстро и не деградирует по мере продвижения к концу выборки.

Но сложность реализации тут не главный трейдоф, на который мы идем. Самое главное ограничение – мы больше не может получить доступ к произвольной странице данных не проитерировавшись по всем разделами.

Вот и получается, что мы выбираем между

Offset Pagination
+ легко реализовать
+ доступ к произвольной странице
- сильно деградирует по мере продвижения в глубину

Keyset Pagination
+ работает быстро вне зависимости от раздела
- сложнее реализовать
- не поддерживает произвольный доступ в принципе (infinite scroll теперь наш лучший друг)

А казалось бы – ЭТО ПРОСТО ПАГИНАЦИЯ! Ладно еще трейдофы вокруг JWT и Session-based авторизации, но тут-то все было просто😢

#программирование

Прошло уже 5 лет, как я читал Максима Дорофеева и его "Джедайские техники" последний раз. И вот, вся "эффективность" выветрилась, я стал больше прокрастинировать, а выгорание уже дышит в спину...

Поэтому сейчас я сел перечитывать эту великолепную книгу (а заодно и Талеба, Канемана и Клира по всей видимости). А заодно вдохновился всеми "правильными" практиками чтения книг – и стал вести конспекты в Obsidian. Чтобы через 5 лет не перечитывать все заново, а просто подглядеть в конспект.

В общем, ближайшее время буду спамить сюда инсайтами по эффективности из конспектов с моим осмыслением🌚

Инсайт дня от Дорофеева – "заставлялка себя" – тоже антихрупка. Она тратится на бытовые дела, занятия спортом, борьбу с соцсетями, видосиками и сериальчиками. А самое главное – она нужна, чтобы делать дела, которые очень хочется прокрастинировать. Хорошая новость в том, что она тренируется. Именно поэтому один из первых советов по эффективности – займись спортом. Т.е. буквально "иди тренируй заставлялку". Плохая новость – ее можно сорвать. Как мышцы, которым нужен отдых, так и заставлялке нужно время, чтобы восстановиться и окрепнуть для новых нагрузок. Именно тут и срывается большая часть вкатунов в эффективность – нельзя записать 500 дел, а потом разом заставить себя их все выполнить. После этого твоя заставлялка откажет – и ты еще полгода будешь лежать бревном.

#продуктивность #Дорофеев

Оп, вот такие активности от хабра мне нравятся! Надеюсь на большое количество ламповых статей об OSS в следующем месяце – с удовольствием буду заходить почитывать)

Ну и, конечно же, сам поучаствую в конкурсе!

И вы тоже – пишите обо всех своих PR'ах в открытые проекты, своих собственных репозиториях и просто об использовании тех открытых инструментов, что вам нравятся! Такие истории и делают комьюнити ламповым)

https://habr.com/ru/specials/898552/

Я нашел лучшую лицензию для Open Source ever!

https://en.wikipedia.org/wiki/Beerware

Лицензия гласит, что вы обязаны угостить автора используемого вами проекта пивом, если вы когда-либо встретитесь. Жаль, менять лицензию на FastStream уже поздно😢

Инсайт дня от Дорофеева

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

Буквально основная идея MVP, которая выросла из метода рационального фланера, сформулированного Талебом в "Антихрупкости".

Очень часто мы грешим тем, что придумываем какое-то идеальное решение проблемы сидя на берегу, а потом ревностно следуем ему. Проблема в том, что сидя на берегу мы не имеем достаточно информации для принятия оптимального решения. Максимум – мы можем построить приблизительный набор шагов и наметить промежуточные цели. Но мы же строим ПЛАН и в таком случае:

1) По мере следования к цели мы получаем все больше дополнительной информации, на основе которой можно было бы принять более оптимальные решения на промежуточных шагах. Но мы же ослеплены изначально выбраным курсом и просто упускаем такие возможности

2) Мы превращаем выполнение задачи в слона, которого больше хочется прокрастинировать, чем реализовывать

3) Четко продуманный набор действий дает нам иллюзию контроля над неопределенностью – и мы перестаем закладываться на непредвиденные обстоятельства, которые обязательно случатся по ходу следования плану. И тут с нами играет злую шутку эффект выпрямления сроков

В общем, гораздо рациональнее будет сформулировать промежуточную цель и только первые пару шагов по ее достижению. Так мы и с прокрастинацией боремся, и решение будет удачнее, да и в сроки вероятнее всего уложимся

#продуктивность #Дорофеев

И веселая иллюстрация из книги в догонку

Только посмотрите, как FastStream замечательно смотрится в документации FastAPI!

К слову, это может стать правдой, если Tiangolo не пошлет нас нахер😅

https://github.com/fastapi/fastapi/pull/13618

В общем, дискуссия под PR может получится знатной

Недавно размышлял о том, чем же отличается хороший API библиотеки от плохого. Пытался сравнить свои субъективные ощущения от Litestar и FastAPI. Почему Litestar мне не нравится, и в чем феномен успеха FastAPI при всем его минимализме?

Пришел к интересному выводу – многофункциональность хорошего инструмента должна обеспечиваться его минимализмом

Если у тебя есть два приложения / продукта / библиотеки / фреймворка, выполняющих одну задачу, то пользователь выберет тот, что проще. Зачем напрягать лишний раз извилины ради достижения идентичного результата?

Т.е. задача хорошего продукта (а API – это тоже продукт) – закрыть потребность пользователя минимально необходимым набор фич. Но очень многие это не понимают. Часто сталкиваюсь с утверждением "больше = лучше". Давайте воткнем больше информации в UI, давайте запилим 5 способов сделать то же самое. И в итоге получаются монстры, которыми просто невозможно пользоваться. Чтобы этого не случилось как раз и нужны UX / DX специалисты.

Но как закрыть потребность меньшим набором фич, чем у конкурентов? Тут дело в СИНЕРГИИ

Хороший API – это синергирующий API.

Представим, что у нас есть фича X1, которая закрывает потребность Y1. И фича X2, закрывающаю Y2.

Тогда синергиющий API дает нам следующую формулу:

X1 + X2 = Y1 + Y2 + Y3 (сумма двух фич позволяет закрыть потребность Y3, которую фичи не закрывают по отдельности).

Плохой дизайн – это когда сумма X1 + X2 = Y1 + Y2. Т.е. на каждую потребность пользователя у нас есть своя фича, которую пользователю нужно освоить. Именно этим мне и не нравится Litestar – там слишком много уникальных механизмов и зон ответственности, куда он лезет.

Ужасный дизайн – когда фича X1 = 0.8Y1. Т.е фича даже не закрывает кейс, ради которого была создана, а ломается на краевых ситуациях и вынуждает костылить.

#litestar #программирование

Продолжаю делиться своими выжимками из "Джедайских техник" Дорофеева.
Например, мне очень понравилось, как он сформулировал основные проблемы с продуктивностью, которыми грешит большинство из нас:

1. Эффект мегакреативности - мы генерируем множество идей по кругу, т.к. они постоянно вылетают у нас из головы. Надо было фиксировать, что мы там надумали
2. Эффект дырявого стека - мы держим в фокусе только последние задачи, старые просто вытесняются. Надо было фиксировать
3. Нелинейная зависимость времени от сложности - сложные задачи человек более склонен прокрастинировать (задача на 2 часа делается за 2 часа, задача на 6 часов делается за 2 дня). Надо формулировать задачи проще и делать понятными частями
4. Неэкономия масштаба - мыслетопливо тратится на удержание списка дел в голове, а не его выполнение. Больше список - больше "утечек". Надо выгружать память на внешние носители и концентрироваться на работе, а не списке дел
5. Выпрямление сроков - отклонения от сроков всегда происходят "вверх". Люди прокрастинируют время, отложенное "про запас". А когда что-то идет не так, сроки срываются, т.к. "про запаса" больше нет. Надо было делать по чуть-чуть сразу
6. Бракованный день - мы считаем, что все наши задачи требуют много времени и поэтому прокрасинируем недостаточно большие отрезки, когда "тут я ничего не успею сделать". А надо было формулировать задачи так, чтобы они укладывались в пятиминутки.

Отсюда же и следуют основные рецепты продуктивности – не держим в голове лишнее, выгружаем все-все во внешнюю систему (которой мы ДОВЕРЯЕМ и ПОЛЬЗУЕМСЯ!). Ну и делаем... хотя бы по чуть-чуть, но постоянно.

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

#продуктивность #Дорофеев

Самый главный инсайт из книги Дорофеева для меня – это как раз история про то, что большие дела действительно можно делать небольшими подходами. Например, сам Дорофеев начинал писать свою книгу подходами по 30 минут 2 раза в неделю (и за пару месяцев до окончания перешел на ежедневную работу над книгой). То, что буквально 20-30 минутные подходы к "слону" дают результат на долгосроке – это, конечно, логично. Но моя психика просто отказывается это воспринимать... Всегда хочется найти этак часа 3-6 одним куском и "ух, как поработаю". А таких кусков нет – и ты прокрастинируешь все 20-40минутные "огрызки"😢

А еще – мы все неэффективны. Даже те, кто сильно старается. Даже те, кто учит быть эффективными других. Пресловутые "Джедайские техники" (книга об эффективности) были написаны с 3го раза. Так как первые 2 загубила прокрастинация🤷

#продуктивность #Дорофеев

Всем привет! У меня неожиданная новость – Вячеслав ("Программирование и иже с ним")

– https://www.youtube.com/@programming_etc
– https://www.twitch.tv/vyachek_proger
– @pythons_boys

Пригласил меня на стримчик в

Это воскресенье 27 апреля, в 13:00 МСК – Twitch

Пообщаться за программирование и иже с ним. Планируется неформальные ламповые посиделки на часик-другой-третий (возможно с пивом), где будем общаться на темы ИТ и отвечать на вопросики из чата (но вопросы из донатов в приоритете). Так что, всех заинтересованных – welcome! Не забудьте добавить напоминалку в календарь🌚

Вячеслав уже показывал на своих стримах работу с FastStream в реальных приложения, так что я тоже не мог упустить возможность пообщаться с реальным пользователем своего фреймворка😅

Я все пробовал-пробовал для себя uv, чтобы собрать больше фидбека, набить больше шишек и рассказать вам о своих впечатлениях о проекте.

Но все нюансы разобрали уже без меня и гораздо лучше: https://habr.com/ru/companies/otus/articles/903578/

Если кому-то все еще интересно мое мнение на тему uv – он просто работает. Причем работает великолепно. Быстрее, выше, сильнее pip. Самый топ для меня, что я могу воткнуть uv в любой проект через uv pip install – и он поставит все 100500 зависимостей за пару секунд. Ну и бустрапинг чистого проекта тоже приятный.

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

Обновил описание канала. А то как будто на него натыкаются люди, которые не знают, куда попали... А тут дичь полным ходом без описания даже😅

Как думаете, стоит делать еще навигацию по темам? Где TDD обсуждали, где продуктивность, где ссылки на выступления и тд

И, наверное, подчищу посты с релизами FS. Изначально я вообще не планировал сюда что-то постить кроме этого, но потом что-то пошло не так...

Подход Дорофеева с абузом быстрой и медленной системы Канемана натолкнул меня на пару интересных мыслей о карьере, которыми я хочу поделиться с вами.

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

Если приложить эту идею к карьерным грейдами, то мы получаем следующую картину:

Переходы с грейда на грейд обусловлены выполнением задач совершенного разного масштаба и степени неопределенности

– закрой багу / реализуй фичу
– напиши сервис
– создай систему
– организуй работу команды для выполнения тактических задач
– декомпозируй стратегические задачи на тактические
– сформируй стратегические задачи, продвигающие компанию к вижену
– сформируй и транслируй вижен

Переход с грейда на грейд зависит от твоей способности выполнять задачи нового масштаба и более высокой степени неопределенности.

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

К этому можно прийти либо эмпирически через опыт, либо напрямую. В любом случае, победа над рефлексом "прокрастинировать сложные задачи" и выработка рефлекса "выделения следующих шагов, приближающих к выполнению задачи" - лучший навык как для личной эффективности, так и для построения успешной карьеры.

Напоследок приведу пример задач разного уровня:

– "Закрой багу Х"
1) воспроизведи проблему
2) напиши красный тест для стабильного воспроизведения
3) локализуй проблему
4) реши проблему (может быть декомпозирована еще)
5) проверь, что остальные тесты не сломались
6) пуш, ревью, релиз, профит

– "Реализуй поиск в нашем маркетплейсе" - как???
– "Повысь конверсию поисковой выдачи" - чего???
– "Повысь качество поисковой выдачи" - что значит "улучшить качество" вообще!?
– "Повысь размер среднего чека / количество успешно доведенных до продажи сессий" - WTF!?

Естественно, люди, способные решать задачи из списка со звездочкой, значительно ценнее для бизнеса. Что выражается в их позиции, зоне ответственности и денежной компенсации.

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

Что как, заканчиваем на этом с продуктивностью и возвращаемся к программированию?😅 А то я тут уже следующую книгу перечитывать начал. Да и по Дорофееву хотелось бы еще разобрать основные проблемы с продуктивностью.

#продуктивность #Дорофеев #карьера

Очень классно и душевно пообщались с Вячеславом! Про OpenSource почти не было, но классно поговорили за ИТ, путь в разработке, разработчиков / программистов, выгорание и многое-многое другое. Хотя по итогу 3 часа даже как будто мало😅 Надеюсь, экспромт удался

Запись можно посмотреть на youtube

Звук немного шакалит (микрофон я уже заказал, на днях приедет), прошу прощения😢

Вот тут я упоминал эффект синергии для продуктовых фич (и пользовательского API как продукта). А теперь давайте попробуем взять правило Парето, концепцию T-shape, обучения и синергии – и скрестим все вмести.

Допустим, у нас есть знание x, принадлежащее области деятельности X. Допустим, это знание соответсвует правилу Парето и 20% знаний позволяет закрывать 80% задач из этой области. Или, если коротко:

∃x∈X: 0.2x → 0.8X, x → X

Тогда, возьмем две такие области знаний и изучим их обе на 20%:

0.2x + 0.2y = 0.8X + 0.8Y + N,
где N∈[0, 1) - эффект синергии знаний x и y

А теперь давайте вычтем наше получившееся уравнение из следующего базиса

x = X

Получаем что-то такое

x - 0.2x - 0.2y = X - 0.8X - 0.8Y - N
Или
0.8x - 0.2y = 0.2X - 0.8Y - N

Теперь, если считать скорость изучения знаний x и y сопоставимой, то мы можем произвести следующую замену: x = y = t (время изучения).
И получим

0.6t = 0.2X - 0.8Y - N
Или
0.2X = 0.8Y + N + 0.6t

Получается, что не слишком глубокое (чисто по правило Парето) изучение разных синергирующих областей дает вам существенный буст как в рамках объема накопления знаний, так и возможного поля действий и решаемых задач.

Однако, часть задач, которые требует глубоких знаний одной области, будут для вас недоступны. Поэтому вы сами должны решать, что вам важнее – решать широкий круг совсем разных задач за счет изучения множества знаний и эффекта синергии между ними или узкоспециализированные задачи за счет глубоких знаний.

Но очевидно, что поверхностное изучение смежных тем позволит вам значительно быстрее (и за меньшие трудозатраты) расширить базу доступных вам знаний и круг решаемых вами задач. В этом и есть концепция T-Shape.

Однако, это работает не всегда. И в следующем посте я как раз хочу рассказать свои размышления на тему краевых ситуций, когда это не работает.

#продуктивность

Ура-ура-ура! Работа от Astral над новым mypy на Rust кипит!
Уже есть плейграунд, где можно с ним поиграться

https://playknot.ruff.rs/

Пысы: ссылку стащил в @cpython_notes

На самом деле, это прям та штука, которую я больше всего жду в экосистеме Python сейчас (ну и нормальный web-фреймворк, ага)

Совершенно случайно наткнулся на грейдовку Avito, которая лежит в публичном доступе на гите:

https://github.com/avito-tech/playbook/blob/master/developer-profile.md

Очень многие пункты оттуда про компетенции и развитие навыков разработчика сильно коррелируют с тем, о чем я говорю на этом канале – умение декомпозировать задачи с разной степенью неопределенности, сильная вовлеченность в бизнес-процессы. Если вы присмотритесь, то хард-скилы, связанные с написанием кода как такового актуальны только до E3 уровня (грейдовка идет E1-E8), дальше грейдовка предлагает смотреть совсем на другие аспекты.

Лично я себя оценил где-то между E6 и E8, что как раз и получается E7 в среднем (но на деле, конечно, ниже)🌚 Anyway, точную калибровку сам себе ты провести не можешь, да и не важно это на самом деле.

К слову, если у кого-то есть подобные ссылки на публичные грейдовки других крупных компаний – закиньте в комменты, я их тоже прикреплю к посту.

UPD:
Статья о грейдировании KTS – https://habr.com/ru/companies/kts/articles/862348/
Подкаст Podlodka о грейдах в F(M)AANG – https://www.youtube.com/watch?v=zzuOvQzerFk&ab_channel=Podlodka

#карьера

Да уж, сплит-клавиатуры – это для сильных духом. От момента, когда я поехал в магазин за этим чудом до полной рабочей сборки прошло около 2ух недель (с 15 апреля по 1 мая). Давайте, я вам немного расскажу, как это работает.

Еще в том году я писал, что задумался о покупке сплита и вынашивал эту идею. На действия меня сподвиг подарок сертификата в Geekboards на день рождения. 10к на дороге не валяется – будем покупать там! Клавиатуру решил выбирать от Ergohaven, т.к это единственный промышленный производитель, что я нашел – у них есть клавиатуры всех возможных форм-факторов, которые можно потыкать и выбрать подходящий вариант (думал я). К слову, Geekboards являются ретейлером Ergohaven, так что у них в шоуруме должна быть вся линейка сплитов от производителя (наивный)

В общем, 15 апреля еду я в шоурум Geekboards тыкать всякие-разные сплиты с четким намерением купить все в тот же день. Приезжаю – а в шоуруме в наличии всего один витринный образец, у которого еще и трекбол не работает. Остальное - заказывайте с сайта.

– "Вы знаете шоурумы, где можно потыкать всю линейку Egrohaven?"
– "Нигде, заказывайте с сайта вслепую".

На сайте у Geekboards в наличии было всего 3/10 моделей, поэтому

– "А когда ожидается ближайшая поставка от производителя, чтобы я заказал интересную мне модель?" (что у меня не получится его потыкать я уже смирился)
– "не знаю, когда-нибудь"

В общем, в шоурум Geekboards я скатался просто так, спасибо что еще нахер не послали.

В расстроенных чувствах тем же вечером я сел разглядывать сайт Geekboards подробнее и таки нашел интересную мне модель Ergohaven K03 Pro – и сразу же заказал ее СДЕКом.

Через пару дней она пришла, но выяснилось 2 маленьких нюанса
1) клавиатуру мне прислали без свичей и кейкапов (тут как бы сам виноват, но на сайте Geekboards нихера не понятно)
2) мне прислали две ЛЕВЫХ половинки от РАЗНЫХ моделей клавиатуры

Пишем в поддержку! Прикладываю фотки, описание, почему это две левые половинки и я не тупой. – На следующий день мне приходит отбивка "Мы все выяснили, вам прислали правильно, просто переверните одну из половинок"🤯 Тут моя жопа отправилась в стратосферу и я написал новое письмо – с еще большим количеством фоток и аргументов, почему половинки разные. Еще через сутки поддержка со мной согласилась, признала свою вину и предложила заехать на неделе в шоурум, где я смогу докупить свичи, кейкапы и произвести обмен своих половинок. Звучит разумно – едем в шоурум.

В конце недели я приезжаю в шоурум Geekboards во второй раз и выясняется
1) курьер с доставкой моего заказа со склада задерживается уже на 3 часа и его надо подождать еще часок (обещали, что заказ будет в магазине в 15, я приехал в 18, ждал до 19)
2) в шоуруме свичей и кейкапов в наличии НЕТ, их снова нужно заказывать с сайта. Благо, мы нашли хотя бы 3 разных модели свичей по 1 штучке, чтобы вставить их мне в клаву и я хоть выбрать смог, что заказывать

Ладно, производим замену половинок и спрашивает
– "А что там по скидке на свичи за неудобства?"
– "Не знаю, мне ничего про тебя не говорили. Вот твоя половинка, ничем не могу помочь"

Пишем в поддержку! – мне дают промик на 5% (сэкономил 120р на свичах, спасибо). А вот с кейкапами вышла накладка – под мою модель на сайте Geekboards их не было в принципе. Пришлось заказывать от производителя и ждать, когда они приедут с Краснодара.

В общем, 1го мая ко мне приходят свичи, кейкапы – я бегу их радостный забирать, думая что история закончилась... Но после сборки выясняется интересный нюанс – мак видит только ту половинку, что воткнута в него в текущий момент. Вторая половинка для него просто невидима🤯

#split