Код на салфетке – Telegram
Код на салфетке
2.21K subscribers
745 photos
14 videos
2 files
788 links
Канал для тех, кому интересно программирование на Python и не только.

Сайт: https://pressanybutton.ru/
Чат: https://news.1rj.ru/str/+Li2vbxfWo0Q4ZDk6
Заметки автора: @writeanynotes

Реклама и взаимопиар: @Murzyev1995
Сотрудничество и др.: @proDreams
Download Telegram
Знаете ли вы, что генераторы помнят где остановились между вызовами?

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

Простой пример – генератор считает и помнит счетчик:

def counter():
count = 0
while True:
count += 1
yield count

gen = counter()
print(next(gen)) # 1
print(next(gen)) # 2
# Сходили за чаем, вернулись
print(next(gen)) # 3 - помнит где остановился


Каждый next() продолжает с того места где yield остановился. Переменная count не исчезает между вызовами – она заморожена внутри генератора.

Еще интереснее с несколькими переменными и сложным состоянием:

def fibonacci():
a, b = 0, 1
while True:
yield a
a, b = b, a + b

fib = fibonacci()
print(next(fib)) # 0
print(next(fib)) # 1
print(next(fib)) # 1
print(next(fib)) # 2
# 2_days_later.jpg
print(next(fib)) # 3 - обе переменные a и b сохранились
print(next(fib)) # 5


Обе переменные a и b остаются в памяти между вызовами. Генератор не пересоздается каждый раз, он просто продолжает с замороженной точки.

Проверим, что состояние действительно сохраняется внутри объекта:

def stateful_gen():
state = {'calls': 0, 'sum': 0}
while True:
value = yield state['sum']
state['calls'] += 1
state['sum'] += value

gen = stateful_gen()
next(gen) # Инициализация
print(gen.send(10)) # 10
print(gen.send(20)) # 30
print(gen.send(5)) # 35
# state живет внутри генератора между вызовами


Словарь state существует в памяти генератора постоянно. Это не просто локальная переменная функции – это часть состояния генератора, которое Python сохраняет в специальной структуре.

А вот пример где генератор обрабатывает файл порциями и помнит позицию:

def read_chunks(filename, chunk_size=1024):
with open(filename, 'r') as f:
position = 0
while True:
chunk = f.read(chunk_size)
if not chunk:
break
position += len(chunk)
yield f"Read {len(chunk)} bytes, total: {position}"

# Создаем тестовый файл
with open('test.txt', 'w') as f:
f.write('x' * 5000)

reader = read_chunks('test.txt', 1000)
print(next(reader)) # Read 1000 bytes, total: 1000
print(next(reader)) # Read 1000 bytes, total: 2000
# Делаем другие задачи...
print(next(reader)) # Read 1000 bytes, total: 3000
# position не сбросился, файловый дескриптор жив


Переменная position и открытый файл живут между вызовами. Генератор держит весь контекст выполнения включая file handle.

Как это работает под капотом? Python создает специальный объект генератора с полями gi_frame (stack frame), gi_code (байткод), gi_yieldfrom (для yield from); все локальные переменные хранятся в gi_frame.f_locals. А когда вызываем next(), Python восстанавливает stack frame и продолжает выполнение с инструкции после yield.

Генераторы сохраняют полное состояние выполнения между вызовами через замороженный stack frame. Это позволяет писать итераторы которые помнят где остановились, обрабатывать бесконечные последовательности, держать открытые ресурсы между вызовами. Но – если генератор держит открытый файл или соединение, не забывайте вызывать gen.close() для cleanup.

Код на салфетке x Кусочки кода
🔥121👍1
173 человека. 11 призов. 3 дня.

Статистика на вашей стороне, друзья. Шансы выиграть неприлично высокие 🔥

Если вы ждали знака свыше, чтобы испытать удачу — это он. Результаты уже совсем скоро, так что не тяните!

Прыгай сюда 👉 https://news.1rj.ru/str/press_any_button/1384
И другу перешли, пусть тоже попробует!
🔥6😱3
Всем привет!

На сайте небольшое, но важное обновление: мы объединяем комментарии!

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

Теперь всё работает через виджет Telegram.

В чём плюсы для вас:
Одна дискуссия: комментарии под статьей на сайте и постом в канале теперь синхронизированы.
Никаких лишних регистраций: чтобы написать на сайте, достаточно просто залогиниться через Telegram.

Теперь обсуждать новости стало намного проще и удобнее. Заходите проверить!

Пост на сайте

Как вам изменение? 👇
🔥53👍1
Kawai-Focus 2.1: переезд на новый стек
Автор: Eugene Kaddo

Данная статья посвящена:
- Причинам ухода с Kivy;
- Переезду проекта на новый стек: FastApi + Vue.js + Tauri + Ionic;
- Сборке приложения под Linux в AppImage.


Читать статью на сайте
Читать статью на Хабр

Поддержать проект через YooMoney
Поддержать проект через Tribute в Telegram
Поддержать проект через наш Telegram-бот

#Python #Kivy #Open_source #Наши_Open_Source_проекты #Kawai.Focus #Tauri #Nuitka #Ionic #Vue.js #FastApi
🔥41🥰1🎉1
Мой внутренний перфекционист негодует 😤

Летом в розыгрыше участвовало 115 человек. Сейчас нас уже 202! У меня появилась навязчивая идея: хочу удвоить летний результат. Нам нужно ровно 230 участников (или больше, я не против 😉).

Остался всего один день. Давайте закроем этот гештальт! С вас — нажатая кнопка, с меня — 11 крутых призов завтра.

👇 ТЫК СЮДА
https://news.1rj.ru/str/press_any_button/1384
🔥7😱3
Всем доброго вечера пятницы!

«Мгла» (2007)

Эта экранизация повести Стивена Кинга, которая бьёт не только монстрами, но и по психике. Фильм начинается с обычного небольшого городка, над которым после грозы опускается плотный туман, а люди, оказавшиеся в супермаркете, внезапно понимают: снаружи что-то есть, и туда лучше не выходить.

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

Приятного просмотра!
🔥81
Код на салфетке
Новогодний розыгрыш от Код на салфетке, Bothost и сообщества! Новый год уже не за горами, а это значит, что наступает пора дарить подарки! Мы тоже не остаёмся в стороне и приготовили для вас розыгрыш с 11-ю крутыми призами! Что за призы? - 2x Толстовка с…
Определены победители розыгрыша!

Встречайте:
1. BabaVoss_1 (5406978423) — Толстовка с большим принтом
2. anyanyany0 (986539643) — Толстовка с большим принтом
3. MixxArtError (2131769945) — Футболка с большим принтом
4. kazumaiq (881379104) — Футболка с большим принтом
5. starl_ae (1014329713) — Футболка с маленьким принтом
6. BothostMaster (8395870342) — Футболка с маленьким принтом
7. eeclover (6502265621) — Футболка с маленьким принтом
8. jigan_one (192588386) — Блокнот с логотипом
9. Suseng (845226489) — Блокнот с логотипом
10. scwayer (436505120) — Блокнот с логотипом
11. RBXTelega1 (5782683757) — Секретный приз
🔥112🤯1🎉1
Всем привет!

Вот и отгремел наш новогодний розыгрыш! Участников набралось какое-то невероятное количество — рекорд летнего розыгрыша не просто побит, а уничтожен! Спасибо вам за эту активность!

Одиннадцать счастливчиков уже определены (и даже переопределены, список в посте выше), в ближайшее время я свяжусь с каждым для уточнения адресов. Давайте поздравим победителей в комментариях!

➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️➡️

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

Отдельная благодарность администратору BotHost за помощь в проведении розыгрыша. И, конечно, спасибо нашему сообществу за поддержку, особенно:
- @arduinum628
- @Art_py
- @v_pyatnitsky
- @Vladimir_Mikhaylov
- @TakeMy_Revolution
- @Murzyev1995
- @Goldin_Ramon_79
- @lifeindarkside

Оставайтесь с нами, впереди ещё много интересного!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥152❤‍🔥1
Код на салфетке pinned «Всем привет! Вот и отгремел наш новогодний розыгрыш! Участников набралось какое-то невероятное количество — рекорд летнего розыгрыша не просто побит, а уничтожен! Спасибо вам за эту активность! Одиннадцать счастливчиков уже определены (и даже переопределены…»
This media is not supported in your browser
VIEW IN TELEGRAM
ПАРАДОКС СЕНЬОРА: ПОЧЕМУ 4 ЧАСА ПРЕВРАЩАЮТСЯ В 2 НЕДЕЛИ

Вы когда-нибудь задумывались, почему задача, которая объективно занимает 3-4 часа кодинга, в официальном плане растягивается на две недели? Если вы думаете, что это лень, то вы просто не знакомы с когнитивными искажениями и теорией оценки рисков.

Разберем, из чего на самом деле состоит оценка опытного айтишника, и почему «честные» оценки - это прямой путь к провалу проекта.

➡️➡️⤴️⤴️🔄⤴️⤴️➡️🔘

🏃‍♂️ ОШИБКА ПЛАНИРОВАНИЯ И ЗАКОН ХОФШТАДТЕРА

Любая оценка начинается с оптимизма. Но согласно «Ошибке планирования» (Planning Fallacy) Канемана и Тверски, мы склонны оценивать сроки, исходя из «лучшего сценария», игнорируя прошлый негативный опыт.

Тут вступает в силу Закон Хофштадтера: любая задача всегда занимает больше времени, чем вы ожидаете, даже если вы учитываете закон Хофштадтера (да-да, это рекурсия). Поэтому те самые 3-4 часа «чистого времени» - это лишь вершина айсберга.

🏃‍♂️ КОНУС НЕОПРЕДЕЛЕННОСТИ И ПОРЯДОК ХАОСА

Почему сеньор накидывает «пару дней» на инфраструктуру и требования?
🆓🔴Конус неопределенности: На старте задачи неопределенность может достигать фактора 4x. Мы не знаем, отвалится ли сеть рабочая или изменятся ли требования завтра.
🆓🟡Статистика Standish Group (CHAOS Report): Лишь 16,2% IT-проектов завершаются успешно (вовремя и в бюджет). Около 52,7% считаются «спорными» (задержки, перерасход), а 31.1% - полным провалом.

Сеньор - это человек, который не хочет попасть в эти 30% и знает: зависимость от смежных команд может увеличить срок в 2 раза, а от внешних партнеров - в 10 раз.

😠 МЕТОД PERT: КАК ПРЕВРАТИТЬ ГАДАНИЕ В НАУКУ

Вместо того чтобы просто накидывать время «на глаз», в управлении проектами используют метод PERT (Three-Point Estimation). Это способ учесть риски математически.
Метод учитывает три точки:
🆓0️⃣Оптимистичная (O): 4 часа
🆓1️⃣Наиболее вероятная (M): 2-3 дня (с учетом личных дел и митингов)
🆓2️⃣Пессимистичная (P): 1-2 недели (учитывая «богатство» компании и возможный хаос)

Формула PERT (O + 4M + P) / 6 превращает ваши предположения в обоснованный взвешенный прогноз. Сеньор интуитивно считает именно так, закладывая обязательный резерв, которого всё равно всегда не хватает.

🥰 НАЛОГ НА МЕНТАЛЬНОЕ ВЫГОРАНИЕ И ЗАКОН ПАРКИНСОНА

Сеньор знает: работа заполняет всё время, отпущенное на неё (Закон Паркинсона). Если вы сделаете задачу за 4 часа и сдадите её сразу, вам тут же накинут новую. Поэтому опытный аналитик закладывает 2 дня на личные дела. Не на безделье, а на восстановление ресурса за счет компании. Оценка сроков в IT - это в первую очередь управление ожиданиями. Если вы не защитите своё время на старте, система просто выжмет из вас все соки, наградив за скорость лишь новыми тикетами в бэклоге.

➡️➡️⤴️⤴️🔄⤴️⤴️➡️🔘

🏃‍♀️ МАТЕМАТИКА СРОКОВ

Складываем всё вместе:
0️⃣ Чистое время: 4 часа.
1️⃣ Коэффициент неопределенности: +2 дня.
2️⃣ Налог на восстановление: +2 дня.
3️⃣ Коэффициент «рисков компании»: от 2 до 7 дней.
4️⃣ Резерв (10–20%): финальный штрих.

Результат: от 7 до 12 рабочих дней на задачу, которая «делается за вечер».

Если вы оцениваете задачи «честно» - поздравляю, вы служите живым щитом для тех, кто оценивает их как сеньор. Вы закрываете чужие риски своим личным временем и нервами.

🤔 А по какой формуле сегодня оцениваете вы? Пишете оптимистичные 4 часа или научно обоснованные 2 недели?

Код на салфетке x Мозг в данных
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥161
Привет, друзья! 👋

Еще одна неделя позади, и у нас накопилось много интересного контента. Вот самые полезные и увлекательные материалы, которые мы выбрали для вас на этой неделе:

📋 Новое на канале:

🔄 Понедельник, 05.01.2026Дайджест

🐍 Вторник, 06.01.2026Знаете ли вы, что генераторы помнят где остановились между вызовами?

🐈 Среда, 07.01.2026 — Изменения на сайте

⚙️ Четверг, 08.01.2026 — Kawai-Focus 2.1: переезд на новый стек

🎬 Пятница, 09.01.2026Пятничный кинорелакс

🍀 Суббота, 10.01.2026 — Победители розыгрыша

Воскресение, 11.01.2026 — ПАРАДОКС СЕНЬОРА: ПОЧЕМУ 4 ЧАСА ПРЕВРАЩАЮТСЯ В 2 НЕДЕЛИ

🔗 Будьте ближе к нам:

🌐 Читайте полные статьи на сайте

💬 Присоединитесь к обсуждению в чате

Спасибо, что остаетесь с нами! Надеемся, что эти материалы будут вам полезны. Удачи в новой неделе! 🚀

#дайджест #код #python #полезное #код_на_салфетке
🔥61
Знаете ли вы, что переменная цикла for может протекать за пределы цикла?

Пишете for i in range(10): в функции, цикл завершается, а переменная i остается доступной со значением 9. В отличие от многих языков, Python не создает новую область видимости для циклов – переменная цикла живет в той же области, где написан сам цикл.

Простой пример – переменная доступна после цикла:

for i in range(5):
print(i)

print(f"После цикла i = {i}") # i = 4
# Переменная i осталась со значением последней итерации


Переменная i не исчезает когда цикл заканчивается. Она продолжает существовать в текущей области видимости.

Это может создать неожиданные баги при вложенных циклах:

# Ищем пару чисел
found = False
for i in range(3):
for j in range(3):
if i + j == 4:
found = True
break
if found:
break

print(f"Нашли: i={i}, j={j}") # i=2, j=2
# j доступна даже после break во внутреннем цикле

# А теперь ошибка
for i in range(3):
pass

for j in range(3):
if i == j: # Используем i из ПРЕДЫДУЩЕГО цикла
print(f"Совпадение: {i}")
# Выведет только: Совпадение: 2


Переменная из одного цикла "протекает" в другой. Если забыли что i осталась со значением 2, получим неожиданное поведение.

Например, в исключениях:

data = [1, 2, 'three', 4, 5]

try:
for item in data:
result = int(item) * 2
print(result)
except ValueError:
print(f"Ошибка на элементе: {item}") # item = 'three'

print(f"Последний обработанный: {item}") # item все еще доступна
# item = 'three' осталась после except блока


Переменная item доступна и после exception, и после всего блока try-except. Это может быть полезно для отладки, но часто приводит к багам.

А вот где это реально опасно – замыкания в циклах:

# Создаем список функций
functions = []
for i in range(3):
functions.append(lambda: i)

# Вызываем функции
for func in functions:
print(func()) # 2, 2, 2 - все функции вернут 2!

# Почему? Потому что i одна для всех, и после цикла i=2
print(f"i после цикла = {i}") # 2


Все lambda функции захватили одну переменную i, а не разные значения. Когда цикл закончился, i стала равна 2, и все функции возвращают 2.

Правильно будет – зафиксировать значение через аргумент по умолчанию:

functions = []
for i in range(3):
functions.append(lambda x=i: x) # x=i фиксирует значение

for func in functions:
print(func()) # 0, 1, 2 - правильно


Кстати, list comprehension в Python 3 создает свою область видимости:

# Python 3
result = [i for i in range(5)]
try:
print(i) # NameError: name 'i' is not defined
except NameError:
print("i не доступна после comprehension")

# Но обычный for оставляет переменную
for j in range(5):
pass
print(j) # 4 – доступна


List comprehension защищен от утечки переменных, а обычный цикл – нет.

Python не создает отдельную область видимости для циклов for. Переменная цикла остается доступной после завершения и может протечь в другие циклы, замыкания и обработчики исключений. List comprehension в Python 3 создает свою область, но обычные циклы – нет. Не забывайте проверять что переменные цикла не конфликтуют с другим кодом, особенно при создании замыканий.

Код на салфетке x Кусочки кода
🔥13👍3
Проснулся 1-го января и переписал библиотеку: релиз async_yookassa 1.0.0
Автор: Иван Ашихмин

Официальный SDK ЮKassa работает на requests и блокирует Event Loop, что критично для ботов и FastAPI. 8 месяцев я не трогал свой async-форк, пока 1-го января мне не напомнили о его существовании. В статье рассказываю, как я полностью переписал архитектуру.


Читать статью на сайте
Читать статью на Хабр

Поддержать проект через YooMoney
Поддержать проект через Tribute в Telegram
Поддержать проект через наш Telegram-бот

#requests #pydantic #httpx #библиотека #Open_Source #Юкасса #Async #YooKassa #ЮKassa
🔥12❤‍🔥1
Приветствую!

«Хищник: Планета смерти» (2025)

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

Чтобы вернуть честь, он отправляется на Генну — планету, прозванную Планетой смерти, где каждый шаг может стать последним. Там Дек неожиданно находит союзника в лице андроида Тии, связанной с корпорацией Weyland-Yutani, и вместе им приходится выживать среди местной фауны, враждебных существ и угроз, которые опасны даже для яутжа. Это история не только о охоте, но и о странном союзе хищника и машины, которые вынуждены доверять друг другу, чтобы не погибнуть.

Приятного просмотра!
🔥7😱2👌21🤣1
Трое в лодке, не считая контекста
Автор: Владимир Пятницкий

Создание MCP-агентов: Полное руководство по разработке и интеграции.

Создание MCP-сервера, создание MCP-клиента, интеграция в приложение на python


Читать статью на сайте

Поддержать проект через YooMoney
Поддержать проект через Tribute в Telegram
Поддержать проект через наш Telegram-бот

#гайды #python #LLM #ИИ #MCP #искусственный_интеллект #ИИ_агенты #model_context_protocol
🔥7😱21
Media is too big
VIEW IN TELEGRAM
🦍 IT И БИЗНЕС: КАК ПЕРЕСТАТЬ БЫТЬ «КОД-МАРТЫШКОЙ» В 2026 ГОДУ

Для бизнеса IT-отдел часто выглядит как черная дыра для бюджета. А разработчики видят бизнес как генератор хаоса, который мешает писать "чистый код".

На дворе январь 2026. Если вы до сих пор просто закрываете тикеты и ждете идеального ТЗ - у меня плохие новости. Технологии улетели вперед, AI пишет бойлерплейт быстрее джуна, а ценность инженера теперь не в знании синтаксиса, а в понимании денег.

Разберем, как перестать быть инструментом и начать управлять хаосом.

➡️➡️⤴️⤴️🔄⤴️⤴️➡️🔘

😘 ЛОВУШКА ИСПОЛНИТЕЛЯ И BUSINESS ACUMEN

Фундаментальный конфликт: бизнес мыслит категориями прибыли (зачем это нужно), а IT мыслит категориями синтаксиса (как это сделать). Пока этот разрыв существует, вы проигрываете.

🆓📉 Ловушка исполнителя. Если вы просто "пишете код по ТЗ", вы добровольно становитесь инструментом. Инструмент не задает вопросов, но его легко заменить, когда он ломается или устаревает. Слепое выполнение = создание легаси-кода, который никому не нужен.
🆓🧠 Business Acumen (Бизнес-чутье). Единственный способ выбраться из ловушки. В 2026 году стыдно не знать, как ваша компания зарабатывает. Если вы не можете объяснить, как конкретная фича принесет деньги - не пишите код. Идите к заказчику и выясняйте бизнес-ценность.
🆓🍴 От "Дыры в бюджете" к Мультипликатору. Как только вы начинаете думать о деньгах, отношение меняется. IT перестает быть "черной дырой", куда уходит бюджет, и становится рычагом, который умножает прибыль. Выбор за вами: быть дорогим калькулятором или партнером по бизнесу.

➡️Но чтобы стать партнером, мало просто "понимать бизнес". Нужно научить ваш код говорить на языке этого бизнеса. И здесь на сцену выходит архитектура.


😵‍💫 СТРОИМ СИСТЕМУ БЕЗ АНАЛИТИКА (DDD LITE)

Когда вы начинаете вникать в бизнес-процессы, вы обнаруживаете, что термины в коде и в реальности не совпадают. Спасает DDD (Предметно-ориентированное проектирование), но без академического фанатизма.

🆓😇 Единый язык. Это база. Если коммерческий директор говорит "Сделка", а в базе у вас таблица Order, а в коде класс Lead - баги неизбежны. Синхронизируйте словарь. Код должен быть читаемым слепком бизнеса, а не абстракцией программиста.
🆓🧱 Изоляция контекстов. Не превращайте проект в "Большой ком грязи". Складской учет должен быть изолирован от бухгалтерии. Изменения в логистике не должны ломать расчет зарплат. Разделяй и властвуй.
🆓🙂 Глубина знаний. Поверхностное понимание задачи рождает поверхностный код. Погружайтесь в предметную область, иначе будете решать выдуманные технические проблемы вместо реальных болей клиента (внутреннего или внешнего).

➡️Хорошо, архитектуру наладили. Но кто будет это реализовывать? Если ждать идеального Проджект-менеджера, можно состариться. Команде придется меняться самой.


📖 РЕЖИМ PRODUCT-MINDED ENGINEER

Отсутствие PM-а в команде - это не повод для анархии. Это повод включить голову и перейти от роли "кодера" к роли "инженера продукта".

🆓🐱 Инженер как Решатель. Мы здесь не чтобы писать строки кода, а чтобы решать проблемы. Иногда лучшее решение - вообще не кодить, а взять готовое SaaS-решение или изменить бизнес-процесс. Это и есть Product Mindset.
🆓👎 Риск "Двойной роли". Когда разработчик сам себе менеджер, велик соблазн накопить "дизайн-долг". Это когда мы срезаем углы в архитектуре, чтобы быстрее закрыть задачу. Держите баланс: скорость важна, но не ценой смерти проекта через полгода.
🆓😑 Экология труда. Руководитель должен создавать давление, чтобы задачи двигались, но без нереалистичных дедлайнов. Выгорание ведущего инженера стоит компании дороже, чем срыв срока на неделю.

➡️Кстати, о скорости и срезании углов. Иногда бизнес требует решения "вчера". И здесь настоящий инженер отличается от перфекциониста умением грамотно "костылить".


🏃‍♂️ ФИЛОСОФИЯ КОСТЫЛЕЙ: ОСОЗНАННЫЙ ТЕХДОЛГ

Костыли - это не грех. Это финансовый инструмент. Это кредитное плечо, которое вы берете у системы, чтобы успеть к релизу.
Please open Telegram to view this post
VIEW IN TELEGRAM
3🔥2
🆓😐 MVP и пожары. Иногда "криво и быстро" сегодня важнее, чем "идеально архитектурно" через месяц. Если бизнесу нужно ехать сейчас, "шашечки" не важны.
🆓☠️ Точка невозврата. Костыль становится ядом только тогда, когда живет дольше месяца и обрастает зависимостями. Это путь к техническому дефолту - состоянию, когда переписать систему дешевле, чем поддерживать.
🆓🥰 Рефакторинг как гигиена. Не ждите "особого спринта" для рефакторинга. Это фоновый процесс. Убирайте за собой сразу, как повар на кухне, возвращая долг системе.

➡️Мы разобрались с кодом, людьми и долгами. Осталось самое сложное - как спланировать работу в условиях, когда всё меняется каждый день?


💄 УПРАВЛЕНИЕ ХАОСОМ

Хаос в разработке - это нормальное состояние. По данным Standish Group, процент провалов в IT всё еще высок. Почему? Потому что мы плохо считаем.

🆓☠️ Task Unpacking. Единственный способ бороться с неопределенностью - дробить задачи. Если задача в плане занимает больше 4 часов - это ложь. Декомпозируйте её до атомов.
🆓🫥 Парадокс планирования. Люди биологически склонны к оптимизму. Всегда умножайте свои оценки на коэффициент риска (обычно x2 или x3). Ни в коем случае не пессимизм, это просто статистика.
🆓🏃‍♂️ Закон Паркинсона. Работа всегда заполнит всё время, отпущенное на неё. Жесткие (но разумные) дедлайны дисциплинируют лучше, чем бесконечный Agile.

➡️➡️⤴️⤴️🔄⤴️⤴️➡️🔘

🤔 А вы кто сегодня: пишете код по ТЗ или реально решаете проблемы бизнеса?


Код на салфетке x Мозг в данных

P.S.: видео с аккаунта в запрещеннограмме pymineral
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍1
Привет, друзья! 👋

Еще одна неделя позади, и у нас накопилось много интересного контента. Вот самые полезные и увлекательные материалы, которые мы выбрали для вас на этой неделе:

📋 Новое на канале:

🔄 Понедельник, 12.01.2026Дайджест

🐍 Среда, 14.01.2026 — Знаете ли вы, что переменная цикла for может протекать за пределы цикла?

⚙️ Четверг, 15.01.2026 — Проснулся 1-го января и переписал библиотеку: релиз async_yookassa 1.0.0

🎬 Пятница, 16.01.2026Пятничный кинорелакс

🤖 Воскресенье, 18.01.2026 — Трое в лодке, не считая контекста, IT И БИЗНЕС: КАК ПЕРЕСТАТЬ БЫТЬ «КОД-МАРТЫШКОЙ» В 2026 ГОДУ

🔗 Будьте ближе к нам:

🌐 Читайте полные статьи на сайте

💬 Присоединитесь к обсуждению в чате

Спасибо, что остаетесь с нами! Надеемся, что эти материалы будут вам полезны. Удачи в новой неделе! 🚀

#дайджест #код #python #полезное #код_на_салфетке
🔥32❤‍🔥1
Знаете ли вы, что and и or возвращают не True/False, а сами операнды?

Пишем result = x or y, ждем булево значение, а там объект x или y. Или используем value = a and b для проверки, а в переменной оказывается один из операндов, вместо True/False. Дело тут в том, что and и or в Python не преобразуют результат в bool – они возвращают один из операндов как есть, в зависимости от их истинности.

Простой пример – or возвращает первый истинный операнд:

result = 5 or 10
print(result) # 5, а не True

result = 0 or 10
print(result) # 10

result = None or "default"
print(result) # "default"

result = "" or "fallback"
print(result) # "fallback"


or проверяет первый операнд – если он правдив (не 0, не None, не пустая строка), то возвращает его. Иначе – вернет второй операнд, не проверяя его на истинность.

С and работает наоборот – он возвращает первый ложный или просто последний операнд:

result = 5 and 10
print(result) # 10, а не True

result = 0 and 10
print(result) # 0

result = "hello" and "world"
print(result) # "world"

result = [] and "never evaluated"
print(result) # []


and проверяет первый операнд – если он ложный, возвращает его сразу. Если истинный, возвращает второй операнд как есть, не преобразуя в bool.

Это позволяет делать короткие условные выражения:

# Установка значения по умолчанию
name = input("Имя: ") or "Аноним"
print(f"Привет, {name}")
# Если ввели пустую строку, name = "Аноним"

# Безопасное обращение к атрибуту
config = None
debug = config and config.get('debug')
print(debug) # None, без ошибки
# Если config = None, второй операнд не вычисляется

# Выбор первого непустого значения
first_name = ""
last_name = "Петров"
display_name = first_name or last_name or "Неизвестно"
print(display_name) # "Петров"


Второй операнд and и or не вычисляется если результат уже известен (short-circuit evaluation).

Особенно опасно в словарях и списках:

# Устанавливаем значение по умолчанию
data = {'name': ''}
processed = data.get('name') or 'Unknown'
print(processed) # 'Unknown'

# Но если значение может быть 0
scores = {'player1': 0}
score = scores.get('player1') or 100
print(score) # то получится 100 – настоящий 0 утерян

# Правильно через get с дефолтным значением
score = scores.get('player1', 100)
print(score) # 0


Пустая строка и 0 являются ложными, поэтому or их пропускает, хотя это валидные значения.

Вот где это полезно – ленивая инициализация:

class Cache:
def __init__(self):
self._data = None

def get_data(self):
# Инициализируем только при первом обращении
self._data = self._data or self._load_expensive_data()
return self._data

def _load_expensive_data(self):
print("Loading...")
return {'key': 'value'}

cache = Cache()
print(cache.get_data()) # Loading... {'key': 'value'}
print(cache.get_data()) # {'key': 'value'} - без Loading


or проверяет кеш, и если он None, вызывает дорогую функцию только один раз.

Операторы and и or возвращают сами операнды, а не True/False. or возвращает первый истинный операнд или последний, and возвращает первый ложный, либо последний. Это полезно для значений по умолчанию и условных выражений, но может создать баги если не учитывать что пустая строка, 0 или пустой список тоже ложны.

Код на салфетке x Кусочки кода
🔥3