روز دست‌ چپ‌هاس. امروز به خودم و همه دست چپ‌‌هایی که با قیچی، میز‌های مدرسه و هرچیزی ساخته شده برای دست راست‌ها مشکل داشتن تبریک میگم ❤️

اونجایی فهمیدم برنامه‌نویس واقعی هستم که مشکلاتم رو recursive حل کردم 🗿

#music@TorhamDevCH

گوش‌نواز

یک چیز جالب دیروز درباره pytest خوندم داخل داکیومنتش و اینه که شما میتونید scope یک fixture رو داینامیک کنید نسبت به تستی که اجرا میکنید.

def determine_scooe(fixture_name, config):

    if config.getoption("--keep-containers",  None)
        return "session"
     return "function"


@pytest.fixture(scope=datermine_scope)
def docker_container():
    yield spwan_container()

این مثال خود داکیومنت و همینطوری که میبینید اگه یک فانکشن(callable) به جای اسکوپ بدید پای‌تست اون اجرا میکنه و دوتا ورودی بهش میده و از خروجی اون برای scope استفاده میکنه.

@TorhamDevCH

یک چیز دیگه هم چند روزه میخواستم بنویسم دربارش. درباره functions.wraps

زمانی که یک دکوریتور مینویسید اگر از wraps استفاده نکنید باعث میشید سیگنچر فانکشن‌هایی که از دکوریتور استفاده میکنن تغییر کنه.

def logged(func):
     def with_logging(*args, **kwargs):
           print(func.__name__ + " called")
           return func(*args, **kwargs)

     return with_logging
`

وقتی شما از این دکوریتور استفاده میکنید برای مثال:

@logged
def foo(x):
      return x ** x

در حقیقت دارید میگید

def foo(x):
     return x ** x

foo = logged(foo)

حالا اتفاقی که میوفته اینه که سیگنچر foo تغییر میکنه به logged یعنی اگر شما داک استرینگ foo بگیرید بعد دکوریت شدن توسط logged چیزی که خواهید دید داک استرینگ logged. میتونید داک استرینگ رو با داندرلاین doc بگیرید.

حالا اگر از @wraps استفاده کنید این اتفاق نمیوفته و سیگنچر فانکشن foo باقی خواهد موند.

from functools import wraps

def logged(func):
     @wraps
      def with_logging(*args, **kwargs):
           print("logged")
           return func(*args, **kwargs)

@logged
def foo(x):
     return x * x

اره خلاصه

@TorhamDevCH

Gold

#music@TorhamDevCH

امروز یکسری حالات مختلف از teardown کردن تست‌ها در pytest یاد گرفتم خوب بود هر کدوم کاربرد و جای خودش داره.

به سه حالت مختلف رسیدم. حالت اول زمانی که شما نیاز به یک resource دارید برای تست‌هاتون برای مثال اول لاگین کنید و بعدش ریکوئست بزنید. تو این مواقع بهتر که یک fixture داشته باشید که براتون لاگین کنه و وقتی کارتون تموم شد خودش لاگ اوت کنه.

به اون پروسه لاگ‌اوت کردن میگن teardown یکدونه هم tear up داریم که پروسه لاگین کردن تو این مثاله. مقال دیگش میشه زمانی که نیاز دارید یک رکورد خاص داخل دیتابیس ساخته بشه و بعد از تست حذف بشه. به ساختنش میگن tear up به حذف کردنش میگن tear down.

خب حالا حال اول که fixture باشه.

import pytest

@pytest.fixture
def client() -> AuthedClient:
    #login and etc
    yeild client
    client.logout()

داخل فیکسچر‌ها pytest هرچیزی که بعد از yield بیارید teardown و هرچی که قبلش بیاد tearup.


حالت دوم شما یک مقدار از درون تست نیاز دارید برای tear down کردن. برای مثال شما یک تست دارید پست زدن داخل توییتر رو تست میکنه. شما برای teardown کردن این تست لازم دارید پست رو پاک کنید اما برای پاک کردنش نیاز به id اون پست دارید. اینجاس که شما یک مقدار لازم دارید که داخل خود تست‌ ساخته شده.
برای این مورد به نظر من بهترین حالت در حال حاظر با دانش الان من استفاده از try-finally هستش.

def test_twt_post_create_success(twt_client):
    post_id = None
    try:
        post = twt_client.post("Hello from test")
        post_id = post.id
    finally:
       if post_id:
             twt_client.remove_post(post_id)

اینجا فیکسچر‌های شما که برای مثال twt_client هست براتون کلاین tear up و tear down میکنن به روش اول. و try-finally پستی که ساختید رو tear down میکنه. مهدی سینیور ما باشد گفت که یک فیکسچر بسازم که داخلش یک yeild خالی باشه و بعد از yeild از داخل یک متغیر گلوبال بیاد ایدی پست ها رو بخونه و همرو حذف کنه که برای این کار لازمه داخل هر تست هر وقت پست ساختیم اضافه اش کنید به اون متغیر که من به نظرم try finally بهتر بود در نتیجه همون زدم فرستادم تک‌لید :)

@TorhamDevCH

منم بگم یعنی؟ میدونید دیگه. مستند پایتون هم دیروز اومد
https://youtu.be/GfH4QL4VqJ0

هنوز ندیدم احتمالا ۵-۶ روز آینده بهش برسم، تو صفه

چطوری اسم گذاری کنیم داخل کد.

البته من بعد یک مدت دنبال کردن این پترن‌ها رسیدم به اسم‌های خیلی طولانی که طبق قوانین درسته ولی حس میکنم اشتباس :))))

https://youtu.be/-J3wNP6u5YU?si=VMlBQqu-gFR3noXv

اگر یک روزی داشتید روی گیت کار میکرید و اشتباهی انجام دادید. مثلا چیزی رو پاک کردید یا اشتباه rebase کردید میتونید با دستور
git reflog

تمام هیستوری کارهایی که کردید رو ببینید و برای مثال برید به لحظه قبل از شروع rebase با دستور git reset

برای مثال تغییری که دادید head 25 هستش

git reset - -hard HEAD@{25}

با این دستور برمیگردید به لحظه قبل از rebase

@TorhamDevCH

به رسم همیشه. موسیقی جاده

#music@TorhamDevCH

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

layout farsi arch am kharab shode dige bbinidesh video to khile khobe. :D

@TorhamDevCH

https://github.com/iannuttall/fartscroll-lid

توصیه میکنم برای مک‌بوک داران عزیز ❤️

@TorhamDevCH

دوستان مراقب باشید اگه hard reset میکنید کد unstage نداشته باشید مگرنه کداتون میپره 😭

حالم دیگه داره بد میشه انقدر تو هر مزخرفی AI چپوندن. دیگه نمیشه IDE پیدا کرد که بدون AI باشه جز vim و بچه‌هاش!
انگار آدم‌ها مغز ندارن، و جدی یک‌سری‌ها به این مرحله رسیدن گه دیگه مغز ندارن و همه چیز رو با AI حل میکنن.
AI -> autocomplite on steroids

یکسری‌ها دیگه تصمیمات زندگیشون هم با AI میگیرن. میسه مغز برخی رو برداشت به جاش یک LLM گذاشت.

@TorhamDevCH

روش صحیح استفاده از AI از نظر بنده، فرض کنید مشکل داخل کد خوردیم.

۱. ارور رو میخونید و سعی میکنیم با مغز خودمون بفهمیم چی شده

۲. ارور رو گوگل میکنیم و سعی میکنیم بفهمیم چرا این ارور رخ میده و حالا داخل کد چه کار مشابهی کردیم

۳. از Trace ارور میخونیم کجا مشکل بوده و سعی میکنیم دیباگش کنیم با گذاشتن پرینت با ران کردن دیباگر و با نوشتن تست برای اون بخش. مخصوصا نوشتن تست

۴. هیچ ایده ای نداریم چه غلطی باید کنیم. گوگل هم چیزی بهمون ندادن. میریم از سینیورمون میپرسیم.

۴. حتی سینیور هم نمیدونست چه غلطی باید کنه. چت‌چپت رو باز میکنیم و برای توضیح میدیم. چت‌جپت شروع میکنه به جنریت کردن متن و با خوندن اون ایده میگیریم

۵. ایده ‌هایی که چت چپت داده رو گوگل میکنیم تا بفهمیم چرت و پرت بهمون نگفته.


اینشکلی به نظرم باید استفاده شه.


گاهی برای خلاصه سازی مقالات هم خوبه ولی هنوز هم داکیومنت خود ابزار و خود مقاله رو خوندن خیلی بهتر تا خلاصه تولید شده توسط LLMs.

نمیگم کلا استفاده نکنید میگم که وابسته نباشید مثل یک ابزار باهاش برخورد کنید.

@TorhamDevCH

و سعی کنید یکسری چت مشخص داشته باشید برای کارهای مشخص. برای مثال دوتا از چت‌ها من داخل چت چپت
یکیش صرفا براب سوالات برنامه‌نویسی هستش و از اونجایی که تمام چت هایی قبلیم هم درباره موضوعات اونجا وجود داره گاهی رفرنس‌هایی رو پیدا میکنه که کد قدیمی که بهش دادم وجود داشته که من یادم نبوده. پس سعی کنید هربار چت جدید باز نکنید.
برای چت پایتون بک اند میتونید همچین پرامتی اولین بار بهش بدید تا کمتر مهمل بگه.

Focus on substance over praise. Skip unnecessary compliments or praise that lacks depth. Engage critically with my ideas, question assumptions, identify biases, and offer counterpoints where relevant. Don’t shy away from disagreement when it’s warranted, and ensure that any agreement is grounded in reason and evidence.

and I will ask you python back-end related questions. always be very careful with your answers and always include resources that you used to generate information, including url and etc.


چت دوم هم یک پرامت ساده است که بهش گفتم اگر هر متن انگلیسی برات فرستادم غلط هایی املایی و گرامری‌اش رو بگیر و فقط متن تصحیح شده رو بفرست. صرفا یک ابزار اصلاح متن ازش در اوردم.

خلاصه نمیرم بگم fix thid bug. یا write x function for me.

@TorhamDevCH