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

Правило: Лучше легко, чем тяжело.

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

В мире кода это выглядит так:

Сложный путь:

def отправить_сообщение(сообшение, сложный_шифр, курьер):
    зашифрованное_сообщение = сложная_функция_шифрования(сообшение, сложный_шифр)
    # Представим, что есть сложный процесс отправки
    результат = сложный_процесс_отправки(зашифрованное_сообщение, курьер)
    return результат

Простой путь:

def отправить_сигнал(сигнал):
    print(f"Показываем сигнал: {сигнал} - и все в курсе.")
    return "Сигнал отправлен"

# Использование функции
отправить_сигнал("✌️")

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

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

#ЗенПитона

Правило: Ясность круче загадочности.

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

В коде это выглядит так:

Загадочный путь:

def проверка(х):
    # Предположим, х это список
    if len([элемент for элемент in х if элемент]): # Что мы тут делаем?
        return "Что-то есть"
    else:
        return "Пусто"

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

Ясный путь:

def проверить_наличие_элементов(список):
    if any(список):  # Прямо и понятно
        return "Что-то есть"
    else:
        return "Пусто"

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

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

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

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

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

3. Слабосвязанные сервисы - наша секретная сеть агентов, работающих автономно, но вместе держащих оборону. Мы погрузимся в искусство внедрения этих сервисов в мир Python, используя наши любимые инструменты, вроде Flask, Django, Celery, чтобы все функционировало как часы.

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

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

#паттерны #фишки #схемы

Правило: Просто – это лучше, чем сложно.

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

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

Сложный путь:
Представь, ты собрался на большое дело, и у тебя есть куча планов: как зайти, кого первого спросить, какие пароли-явки использовать. Ты начинаешь:

def выполнить_дело(время, братва_в_сборе, день):
    if братва_в_сборе > 5:
        if день == "Суббота":
            план = "план А"
        elif день == "Воскресенье":
            план = "план Б"
        else:
            план = "план В"
    else:
        if день == "Суббота" or день == "Воскресенье":
            план = "план Г"
        else:
            план = "план Д"
    return "Идем по " + план

Тут такой завал планов, что и сам забудешь, за чем пришел.

Простой путь:
А теперь представь, ты решил все сделать проще. У тебя один план для всех случаев, без всяких "если понедельник, то...". Ты просто берешь и делаешь:

def выполнить_дело(братва_в_сборе):
    план = "план А" if братва_в_сборе > 5 else "план Б"
    return "Идем по " + план

Тут все ясно: больше народу – один план, меньше братвы – другой. И никаких лишних заморочек.

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

#ЗенПитона

Братья по коду, сегодня мы поговорим о двух мощных инструментах в нашем арсенале – инкапсуляции и абстракции. Эти приемы помогают нам сделать наш код не только крутым и мощным, но и читабельным, как хорошо проложенные улицы в нашем кодовом районе.

Сначала разберемся с urllib и requests:

# Выполняем поиск с помощью urllib
import json
from urllib.request import urlopen
from urllib.parse import urlencode

params = {'q': 'Свинец для кастета', 'format': 'json'}
handle = urlopen('http://api.duckduckgo.com' + '?' + urlencode(params))
raw_text = handle.read().decode('utf8')
parsed = json.loads(raw_text)
results = parsed['RelatedTopics']

for r in results:
    if 'Text' in r:
        print(r['FirstURL'] + ' - ' + r['Text'])

И вот как выглядит код с использованием requests:

# Выполняем поиск с помощью requests
import requests

params = {'q': 'Свинец для кастета', 'format': 'json'}
parsed = requests.get('http://api.duckduckgo.com/', params=params).json()
results = parsed['RelatedTopics']

for r in results:
    if 'Text' in r:
        print(r['FirstURL'] + ' - ' + r['Text'])

А теперь покажем максимальную инкапсуляцию и абстракцию с помощью модуля duckduckgopy:

# Выполняем поиск с помощью модуля duckduckgo
import duckduckgopy

for r in duckduckgopy.query('Свинец для кастета').results:
    print(r.url + ' - ' + r.text)

Инкапсуляция здесь – это как мы упаковываем все наши трюки и данные. В примере с urllib, мы видим каждый шаг, что делает код менее упакованным. Переходя к requests, сложность скрыта за кулисами библиотеки. А модуль duckduckgopy демонстрирует полную инкапсуляцию, скрывая все детали выполнения задачи внутри себя.

Абстракция показывает уровень, на котором мы работаем с задачей. Requests обеспечивает более высокий уровень абстракции по сравнению с urllib, упрощая выполнение запросов. Модуль duckduckgopy предоставляет максимальную абстракцию, позволяя нам сосредоточиться на результате поиска без вникания в технические детали.

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

#паттерны #фишки #схемы

Правило: Сложно – это лучше, чем запутанно.

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

В коде это может выглядеть так:

Запутанный путь:

def обработать_данные(данные):
    # Представим, что тут код, который пытается сделать слишком многое сразу и непонятно
    результат = (какая_то_обработка(данные[0]) if данные else None,
                 другая_обработка(данные[1]) if данные and len(данные) > 1 else None)
    return результат

Здесь попытка сделать код "умнее", добавив в него условные выражения прямо при создании кортежа, делает его трудночитаемым и запутанным. Что если условий будет больше? Код станет настоящим лабиринтом.

Сложный, но четкий путь:

def обработать_данные(данные):
    if not данные:
        return None, None
    обработанный_первый = какая_то_обработка(данные[0])
    обработанный_второй = другая_обработка(данные[1]) if len(данные) > 1 else None
    return обработанный_первый, обработанный_второй

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

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

#ЗенПитона

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

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

Если у нас получается месиво из всех этих зависимостей, то это как если бы весь район вступил в драку – ты меняешь что-то в одном месте, и это отзывается на всех. Чтобы не допустить этого, мы и делим наш код на слои, как районы на зоны влияния: каждый знает своё место и не лезет куда не надо.

На картинке, что выше, у нас трехэтажка, братан:

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

Шаг за шагом мы будем показывать, как эту систему перевернуть так, чтобы всё работало еще круче, следуя одному простому закону – держать все под контролем и по понятиям.

#паттерны #фишки #схемы

Правило: Разговор по делу лучше молчанки.

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

В мире кода это выглядит так:

Молчаливый путь:

def выполнить_задачу(данные):
    if данные is not None:
        # обработка данных
        print("Данные обработаны")
    # Тут без объяснения, почему ничего не произошло, если данные None

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

Разговорчивый путь:

def выполнить_задачу(данные):
    if данные is None:
        print("Ошибка: данные не предоставлены.")
        return
    # обработка данных
    print("Данные обработаны")

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

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

#ЗенПитона

Братья, сегодня разберем одну из хитрых фишек кодерского мира — это как разворот ваших долгов наизнанку, чтобы они работали на вас. Это называется принципом инверсии зависимостей, и это та самая буква D из крутого слова SOLID, что каждый уважающий себя кодер должен знать.

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

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

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

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

И вот эти самые абстракции — это не просто понтовые словечки, это как чистые понятия, которые помогают нам сделать код красивым и понятным. Как модуль duckduckgo, что прячет за собой все сложности поисковой системы.

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

((Все проблемы в информатике можно решить, добавив еще один уровень абстракции)).
Дэвид Уилер

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

А когда мы дойдем до "Первый вариант использования: API фреймворка Flask и сервисный слой" (тут будет ссыль), у нас будет живой пример, который поможет вам это все увидеть яснее.

#паттерны #фишки #схемы

Правило: Но молчанка золото, когда ляпнуть нечего.

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

В мире кода это выглядит так:

Болтливый путь:

def обработать_данные(данные):
    if данные is None:
        print("Предупреждение: нет данных для обработки!")
        # Тут код продолжает выполняться или останавливается, но предупреждение было лишним
    else:
        # Нормальная обработка данных
        print("Данные обработаны успешно")

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

Молчаливый, но эффективный путь:

def обработать_данные(данные):
    if данные is None:
        # Молча возвращаем специальное значение или ничего не делаем, если так задумано
        return None
    # Нормальная обработка данных
    print("Данные обработаны успешно")

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

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

#ЗенПитона

Рубрика: #ПервыйКодНаРайоне — так мы даем понять, что эти посты как раз для тех, кто только начинает свой путь в нашем кодерском мире.

Давайте разберемся с list (списком), братва. Это основной инструмент в питоне для того, чтобы держать элементы в порядке, как братишки в строю. Списки в питоне — это как семейка, где каждый член сидит по номеру и готов помочь в любой схватке. Вот как это работает:

1. Создание списка:
Сначала ты создаешь свою братву:

   братва = ['Васян', 'Петька', 'Колян']
   

Здесь 'Васян' — это пацан номер один, 'Петька' — номер два, и так далее.

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

   братва.append('Саныч')
   

Теперь Саныч — тоже часть нашей улицы.

3. Удаление элемента:
Если кто-то слишком зазнался и пора ему от нас отдохнуть, ты можешь его выкинуть:

   братва.remove('Колян')
   

Колян больше не с нами.

4. Доступ к элементу:
Когда тебе нужно поговорить с конкретным братом, ты просто называешь его номер:

   первый_брат = братва[0]
   

Теперь у тебя есть Васян, и ты можешь с ним порешать дела.

5. Срезы списка:
Если надо собрать нескольких пацанов, можно использовать срез:

   основные_братки = братва[1:3]
   

Теперь у тебя есть Петька и Колян, если он еще с нами.

6. Длина списка:
Чтобы узнать, сколько человек в твоей братве, пользуйся len:

   колво_братвы = len(братва)
   

Понял, сколько нас, понял, на что можешь рассчитывать.

7. Итерация по списку:
Когда надо пройтись по всем и каждому, чтобы дать указания или просто проверить, кто на месте:

   for брат in братва:
       print(брат)
   

Так ты пробегаешься по всей братве, и каждый получит своё слово.



8. Поиск элемента:
Чтобы проверить, есть ли твой брат в строю, используй in:

   if 'Саныч' in братва:
       print('Саныч с нами!')
   else:
       print('Саныча нет на месте.')
   

Это как спросить всех: "Вы видели Саныча?"

9. Получение индекса элемента:
Если тебе нужно знать, под каким номером твой братишка стоит в списке, примени index:

   номер_саныча = братва.index('Саныч')
   

Теперь ты точно знаешь, где твой человек в строю.

10. Проверка наличия и получение индекса:
Можешь объединить эти два действия, чтобы узнать статус братишки и его место, если он есть:

   брат = 'Саныч'
   if брат in братва:
       номер = братва.index(брат)
       print(f'{брат} на своем месте под номером {номер}.')
   else:
       print(f'{брат} сегодня не с нами.')
   

Так ты и проверишь, на месте ли он, и если на месте, то узнаешь его номер.

#ПервыйКодНаРайоне

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

Когда мы болтаем с разрабами про архитектуру, многие вздыхают и говорят, что могло бы быть и покайфовее. Они хотят спасти свою систему, что уже вязнет в своих же багах и зависимостях, как бардак в комнате после трехдневных тусовок. Все эти ребята знают, что их бизнес-логика должна быть чистой, как девчонка из хорошей семьи, но вот как это сделать — голова кругом.
И вот, начинают клепать новую систему, и первым делом колдуют над схемой базы данных, как будто это самое главное. А потом, когда уже весь проект как бы на ногах стоит, вдруг до них доходит: "А давайте-ка мы еще и объектную модель замутим!" И тут все начинает разваливаться, как картонный домик после дождя, потому что важное было на заднем плане.
Короче говоря, первым делом должно быть то, как система себя ведет, а уже потом под это подгоняем хранилище данных. Наши клиенты, пацаны, не хотят знать, как у нас там все устроено внутри. Им важно, чтобы оно работало, иначе они бы и в Excel сами все сделали.
В первой части мы вам покажем, как собрать объектную модель, используя тестирование, и как отвязать эту красоту от технической мороки. Будем рубить код, не зависящий от базы данных, и строить крепкие API вокруг бизнеса.
И погнали мы вам четыре крутых фишки показать:
- Репозиторий — это как наш тайник, где все данные прячем.
- Сервисный слой — это как правила района, кто, куда и зачем идет.
- UoW (Unit of Work) — чтобы наши движения были согласованными.
- Агрегат — чтобы данные всегда были целы и невредимы.
И если вам интересно, куда мы катим, гляньте на рисунок в начале книги. Не парьтесь, если сразу не поняли, по ходу разберем каждый кирпичик.

Так что, братва, вперед, будем штурмовать эти паттерны и делать наш код чистым, как новенький мерс на районе!


#паттерны #фишки #схемы

Правило: В строчке должен быть кайф.

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

В мире кода это выглядит так:

Без кайфа:

def calc(x):
    return x + 10 - 5 * 3 / 2

Этот код работает, но он скучный и неинтересный. Он просто делает расчет по формуле, без какой-либо изюминки или понимания того, зачем и почему.

С кайфом:

def улучшить_настроение(энергия):
    магическое_число = 10
    улучшение = энергия + магическое_число
    улучшение = улучшение - 5  # немного убавим для баланса
    улучшение *= 3  # утроим улучшение
    улучшение /= 2  # поделим на два для идеального баланса
    return улучшение

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

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

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

#ЗенПитона

Правило: Но не настолько, чтобы всюду его искать.

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

В мире кода это выглядит так:

Искать кайф везде:

def сделать_что_то_крутое(данные):
    # Пытаемся применить каждую известную нам хитрость, чтобы код выглядел "круто"
    return ((данные * 2) ** 0.5 / 2).real + [x for x in range(10) if x < 5][-1]

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

С кайфом, но без фанатизма:

def улучшить_данные(данные):
    # Делаем работу понятно и эффективно, с небольшим изяществом
    базовое_улучшение = данные * 2
    финальное_улучшение = базовое_улучшение + 5
    return финальное_улучшение

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

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

#ЗенПитона

#ПервыйКодНаРайоне
Братва, поговорим о кортеже (tuple) на языке улиц, но через призму передачки, знаете такое дело? Кортеж — это твоя передачка в тюрягу. Раз упаковал — и больше не тронешь, всё по канонам.

1. Запаковка передачки:
Собираешь передачку так:

   передачка = ('сиги', 'конфеты', 'чай')
   

Как запечатал и отдал — так оно и дойдет, без вариантов.

2. Доставка до адресата:
Когда пора достать что-то из передачки:

   что_в_передачке = передачка[0]  # сиги на выходе
   

Первое — всегда сиги, как по понятиям.

3. Передачка не резиновая:
Помни, в передачку новое не добавишь:

   передачка[1] = 'кофе'  # Так не прокатит, братан
   

Попытка замены — и сразу нарушение, не туда.

4. Сколько всего в передачке:
Чтобы знать объем:

   всего_в_передачке = len(передачка)
   

Так узнаешь, сколько всего позиций отослал.

5. Разбивка по полочкам:
Если надо всё по полочкам раскладывать:

   сиги, конфеты, чай = передачка
   

Теперь каждый элемент передачки — на своем месте.

6. Проверяем содержимое:
Чтобы никто не обиделся и каждый был учтен:

   for вещь in передачка:
       print(вещь)
   

Пройдешься по всем пунктам — все на месте, чисто.

Короче, кортеж — это твоя четкая передачка, браток. Однажды сделал — и она идет по назначению, без права на переделку. Это как дать слово на зоне: раз сказал, значит так и будет. Используй кортеж, когда надо все держать под контролем и без сюрпризов.
#ПервыйКодНаРайоне

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

1. Предметная область — это наш район, наша территория. Это может быть всё что угодно: от магазина мебели до автосервиса. Главное, это та сфера, где мы крутимся и знаем каждую закладку.

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

3. DDD (Предметно-ориентированное проектирование) — это наш язык жестов или шифры, который позволяет всем участникам бизнеса понимать друг друга без лишних слов. Это помогает всем быть на одной волне и двигаться в одном направлении.

4. Сущность, Объект-значение, Служба предметной области — это как наши ключевые фигуры на районе. Сущности — это главные братки, которые влияют на всё вокруг. Объекты-значения — это вещи, которые важны, но не критичны. Службы предметной области — это наши услуги, которые мы предоставляем на районе, чтобы всё крутилось.

5. Моделирование через тестирование (TDD) — это как проверка нашего плана на прочность. Мы сначала проверяем, всё ли у нас работает как надо, и только потом запускаем в дело. Это помогает нам избегать неприятных сюрпризов и держать всё под контролем.

6. Реальная модель предметной области — это наша карта района, которая отражает реальное положение дел. Это позволяет нам видеть всю картину целиком и понимать, как наши действия влияют на общий результат.

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


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

# Сущности - это как главные братки на районе, только здесь это лекарства
class Лекарство:
    def __init__(self, название, категория):
        self.название = название
        self.категория = категория

# Объекты-значения - это вещи, важные, но не критичные, например, адрес аптеки
class Адрес:
    def __init__(self, улица, номер_дома, город):
        self.улица = улица
        self.номер_дома = номер_дома
        self.город = город

# Служба предметной области - это наши услуги на районе, например, доставка лекарств
class СлужбаДоставки:
    @staticmethod
    def доставить(адрес):
        print(f"Доставляем лекарство по адресу: {адрес.улица}, {адрес.номер_дома}, {адрес.город}")

# Пример использования
парацетамол = Лекарство("Парацетамол", "Жаропонижающее")
адрес_доставки = Адрес("Пушкина", 15, "Санкт-Петербург")
СлужбаДоставки.доставить(адрес_доставки)

В этом коде мы смоделировали типичную операцию для аптеки: имеем лекарство Парацетамол, которое нужно доставить по определенному адресу. Сущность Лекарство отражает ключевой продукт нашего бизнеса. Адрес остается объектом-значением, важным для операции доставки, но не являющимся центром всей системы. И СлужбаДоставки выполняет свою роль, обеспечивая доставку лекарств до клиента.

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

#паттерны #фишки #схемы

Правило: Лучше один раз увидеть, чем сто раз услышать.

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

В мире кода это выглядит так:

Словами:

# Здесь мы описываем, как работает наша функция, используя комментарии
# Эта функция принимает список чисел и возвращает их сумму
def сумма_чисел(список_чисел):
    # Итерируем по списку, суммируя элементы
    сумма = 0
    for число in список_чисел:
        сумма += число
    return сумма
# Пока не запустишь, не увидишь, как она работает на практике.

На деле:

def сумма_чисел(список_чисел):
    return sum(список_чисел)

# Демонстрация работы функции
пример_списка = [1, 2, 3, 4, 5]
print(f"Сумма чисел {пример_списка} равна {сумма_чисел(пример_списка)}")

Здесь мы не только объяснили, что делает функция, но и показали ее работу на конкретном примере. Это сразу дает понять, как функция работает и каков будет результат ее работы.

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

#ЗенПитона

#ПервыйКодНаРайоне
Братва, давайте ка разберемся с set (множеством), но на языке закупок для нашего районного праздника. Множество в Python — это как список покупок, который сам по себе не допускает повторяшек. Ты можешь сколько угодно раз пытаться вписать в него "пиво", но в итоговом списке оно будет только один раз. Вот как это работает на улицах:

1. Создание списка покупок:
Записываем, что нам надо закупить, без повторов:

   закупка = set(['пиво', 'чипсы', 'семки', 'пиво'])
   

Мы два раза "пиво" вписали, но оно учтется один раз, потому что множество — не терпит двойников.

2. Добавление в список:
Если вспомнили, что забыли водку, легко добавляем:

   закупка.add('водка')
   

Теперь в списке покупок есть и водка, но все равно каждый товар — по одному разу.

3. Удаление из списка:
Если решили, что семки — это лишнее:

   закупка.discard('семки')
   

И вот семок уже нет, список покупок чище.

4. Проверка наличия:
Чтобы не забыть про колу, проверяем:

   if 'кола' in закупка:
       print('Кола уже в списке.')
   else:
       закупка.add('кола')
   

Так ты убедишься, что кола не забыта.

5. Проход по списку:
Перед выходом проверяем, все ли взяли:

   for товар in закупка:
       print(товар)
   

Так ты пройдешься по всем пунктам и убедишься, что ничего не забыто.

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

6. То, что надо закупить:
Сначала мы составили список того, что нам нужно для тусы:

   закупка = set(['пиво', 'чипсы', 'водка', 'кола'])
   

7. То, что уже есть на складе:
Потом мы чекнули, что у нас уже есть на складе:

   склад = set(['семки', 'пиво', 'кола'])
   

8. То, что обещали как подгон:
И нам еще обещали подкинуть некоторые вещи:

   подгон = set(['водка', 'сок', 'пиво'])
   

9. Что уже не надо закупать:
Теперь давайте выясним, что нам уже не надо закупать, потому что это либо уже на складе, либо обещали как подгон. Смотрим на пересечения множеств:

   уже_есть = склад.intersection(закупка).union(подгон.intersection(закупка))
   

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

10. Что осталось закупить:
Наконец, вычитаем из нашей первоначальной закупки то, что уже есть или обещано, чтобы понять, что еще надо купить:

   осталось_закупить = закупка - уже_есть
   

Теперь мы точно знаем, что осталось закупить, чтобы не тащить лишнее.

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

#ПервыйКодНаРайоне

Правило: Если реализация трудно объяснить – идея фигня.

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

В мире кода это выглядит так:

Сложно объяснимая реализация:

def выполнить_задачу(данные):
    # Здесь какой-то очень сложный и запутанный код, который использует несколько вложенных циклов,
    # неочевидные условия и трюки с данными, которые трудно отследить и понять с первого взгляда.
    pass

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

Просто объяснимая реализация:

def сортировать_список(список):
    # Используем встроенную функцию Python для сортировки списка.
    # Это просто, понятно и легко объяснимо.
    return sorted(список)

# Простое объяснение: "Функция принимает список и возвращает его отсортированным."

Такой подход легко объяснить любому, кто спросит, как это работает. Это делает код доступным для понимания и поддержки, а также упрощает внесение изменений в будущем.

Как в жизни, так и в коде, важно стремиться к простоте и понятности. Если твоя идея или план выглядит слишком сложным и трудно объяснимым, возможно, стоит пересмотреть подход и найти более простое и эффективное решение.

#ЗенПитона