برای اینکه بفهمین چطور کار می‌کنه، اول یه مثال ساده‌تر رو در نظر بگیرین:

adders = []
for x in [1, 2, 3]:
    adders.append(lambda number: number + x)

for adder in adders:
    print(adder(3))

قاعدتاً باید خروجی‌ها ۴، ۵ و ۶ باشن، درسته؟ چون یه لیست از تابع‌های lambda داره که هر کدوم یه عدد می‌گیرن و x رو بهش اضافه می‌کنن.
ولی در واقع خروجی‌ها ۶، ۶ و ۶ هستن! چرا این اتفاق می‌افته؟
چون این lambdaها تو این مثال closure هستن. تو پایتون، توابع closure زمانی اجرا می‌شن که صدا زده بشن، نه وقتی که تعریف می‌شن! و به متغیرهایی که تو scopeشون هست رفرنس می‌زنن.

def foo():
    adders = []
    for x in [1, 2, 3]:
        adders.append(lambda number: number + x)
    return adders


def main():
    adders = foo()
    x = 5
    for adder in adders:
        print(adder(3))

تو این مثال، x یه بار تو foo تعریف شده و یه بار تو main. وقتی تو main اون closureها رو صدا می‌زنه که تو foo تعریف شده بودن، xی که استفاده می‌کنن همونیه که تو foo بوده، نه اون x تو main.یعنی الان تو این مثال x داخل lambda عدد ۳ میشه نه ۵.
چرا؟ چون داخلش توابع ‍closure یک cell هست که arguement رو ذخیره کرده. و تو همون اسکوپی که تعریف شده اون مدام آپدیت میشه اگه تغییر کنه. بنابراین اینجا چون scope تابع main دیگه با closureمون یکی نیست پس دیگه تغییر نمیکنه.


یک مقاله برای درک بهتر این موضوع تو medium
یک بلاگ راجب اشتباهات رایج تو پایتون این شکلی

@PyBackendHub

Читать полностью…

داشتم کد مینوشتم
یک گافه خیلی بد دادم اصلا حواسم نبود.
باگه این کد کجاست؟

@PyBackendHub

Читать полностью…

https://jsontopydantic.com/
خیلی خوبه. بهش جیسون میدین, بهتون مدل pydantic اون جیسون رو میده. برای integrate کردن api عالیه که سریع یک مدل داشته باشین.

یک ابزار دیگه هم هست که advance تره. یک cli tool هست که بر اساس openapi یا json یا xml براتون مدل پایندنتیک مینویسه.

https://github.com/koxudaxi/datamodel-code-generator/

@PyBackendHub

Читать полностью…

یک پست خیلییی خوب دیدم تو لینکدین حیفم اومد باهاتون به اشتراک نذارم!

لینک پست


تو پست بعدی ترجمه شدشو با chatgpt میذارم
@PyBackendHub

Читать полностью…

این meme رو دیدم خیلی جالب بود… عمق دانشنتون از PostgreSQL تا چه حدیه؟ یکم حس بی سوادی دست داد بهم :)) تو یکی از پستا چند روز پیش راجب یکیش پرداخته بودم 😁

Every sql operator is actually a join? WTF?😂

@ManiFoldsPython

Читать полностью…

من یک پروژه رو چطور توسعه می‌دم؟ شما چطور توسعه می‌دید؟!

ابتدای کار، نه خبری از git هست، نه vscode و نه هیچ لینتر یا پلاگین خاصی. صرفا یه ایده زده به سرم و فقط می‌خوام تست کنم ببینم عملی هست یا نه. (به عبارتی، آیا پتانسیل پیشرفت یا ارزش اینو داره که زمان و انرژی بیشتری روش بذارم؟)

در حدی که کل کار توی یه main.py در میاد! 🫡

اگه پتانسیل رو داشت و به نتایج خوبی رسیدم، راجع بهش پست می‌ذارم و نظر و فیدبک می‌گیرم. رفقا.. اگه ابزار Xی وجود داشت که مشکلاتی از قبیل W و Y و Z رو حل می‌کرد، شما ازش استفاده می‌کردید؟ بنظرتون به چه صورت رلیز شه؟ چطوری در دسترس باشه؟ از قابلیت‌هایی که دوست دارید داشته باشه بگید و..

محدودیت‌ها رو می‌سنجم. مشکلاتی که کاربرها ممکنه باهاش روبه‌رو باشن. موانعی که ممکنه وجود داشته باشه و مانع دسترسیشون به این ابزار باشه. نمیام ابتدا فیدبک بگیرم و بعد تست کنم ببینم آیا پیاده‌سازی میشه یا نه.

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

افراد زیادی هستن توی مارکت که تحت عنوان Solopreneur کار می‌کنن. یک سری از ابزارهایی که شما امروز ازش استفاده می‌کنید (یا شاید پولی بابتش می‌پردازید) توسط این افراد ساخته شدن. بارها دیدم که یه سریاشون حتی می‌گن، تمرکزشون صرفا روی دلیور کردن فیچر به هر قیمتیه. حتی از version controller هم استفاده نمی‌کنن!! فقط push می‌کنن. هیچ تستی هم ندارن! آنچنان کدبیس سنگینی ندارن و اکثر تمرکزشون روی Shipmentه.

مارک لو (Marc Lou) چند وقت پیش یه توییت زد که یکی از ابزارهایی که قبلا درست کرده بود رو بازخرید کرده. گویا ابزار رو طراحی کرده بود و بخاطر شرایط مالی مجبور شد به قیمت ۱۰ هزارتا واگذار کنه به یه تیم دیگه. چند روز پیش بعد از چند ماه دوباره پروژه رو از اون تیم خرید (رایگان) و داره روش کار می‌کنه. نکته‌ای که این وسط هست، زمانی که این پروژه دست Marc نبود، هیچ توسعه‌ای روش انجام نمی‌شد! حالا خود مارک دلیلش رو دقیق نگفت ولی من حدس می‌زدم به خاطر همون طرز تفکر تمرکز ۱۰۰ درصدی روی shipment باشه.

یعنی مارک با این طرز تفکر توسعه این ایده رو پیش برده بود و خب خروجی کار نهایتا یه تیکه کده که صرفا کار می‌کنه، پول می‌سازه و ظاهرا استیبله ولی به چه قیمت؟ نه تست داره. نه تمیزه. نه داکیومنت درستی داره و واسه onboard شدن روش چاره‌ای جز ریویو کردن کد ندارید. خب تمام این مسائل باعث میشن که توسعه این پروژه واسه یه تیم جدید یه معضل باشه. اگه قرار باشه این ایده پول بیشتری بسازه، همزمان با تغییر نیاز کاربرها باید اون ایده هم تغییر کنه و نیازها رو براورده کنه.

ولی خب اون تیم با این خرید، یه حجم خوبی از مارکت رو از وجود خودش آگاه کرد و خیلیم ضرر نکرد!

توییت مارک: https://twitter.com/marc_louvion/status/1834574006827250020

دوست دارم نظر شما رو هم بدونم. شما چیکار می‌کنید؟ فلوی توسعه شما به چه شکله؟

Читать полностью…

An idiot admires complexity a genius admires simplicity - Terry Davis

@PyBackendHub

Читать полностью…

بچه ها یک آپدیت بدم سره قسمت آخر دور sqlalchemy که بحث ماگریشن هاست, و لایوی که قرار بود بریم:
من گلوم التهاب کرده بود هفته پیش, و هنوزم خوب نشده.
این هفته اگه گلوم خوب شه قسمت آخره دوره رو میگیرم. بعد ۲ هفته میرم مسافرت و برمیگردم و اطلاع رسانی میکنم راجب لایو.

@PyBackendHub

Читать полностью…

بنظرم به شدت نرم افزار سمتی رفته که ۹۰درصد مواقع از چیزایی استفاده میکنیم که خیلی overhead دارن و پیچیدگی های زیادی دارن. برای اینکه فکر کنیم سیستممون scalable هست.

یک مقاله ای هست خیلی جالبه. به صورت رادیکال داره ساده فکر میکنه, مثلا استفاده از postgresql برای همه چیز. مثلا queue رو بیایم بررسی کنیم.

بنظرم خیلی ایده خوبیه. شما یک تیبل صف داری, با NOTIFY pg میتونی به consumer بگی از این صف بخونه (بشه pull model نه push model). consumer میاد میگه مثلا ۱ مسیج بده از این صف. مسیج رو لاک میکنه. و SKIP LOCK هم میذاره. یک همچین query ای

WITH locked_message AS (
    SELECT id, message
    FROM queue
    WHERE processed = false
    ORDER BY created_at
    FOR UPDATE SKIP LOCKED
    LIMIT 1
)
UPDATE queue
SET processed = true
FROM locked_message
WHERE queue.id = locked_message.id
RETURNING locked_message.id, locked_message.message;

با یک هیت از دیتابیس یک مسیج میگیره. پردازشش میکنه. و دوباره صبر میکنه تا notification بیاد. به همین سادگی. با کافکا بخوایم مقایسش کنیم,

مزایاش:
- به شدت ساده.
- throughput خوب
- نداشتن مشکل دو ژنرال. میتونید تو یک transaction هم مسیج رو بخونید و هم کارای دیگتون رو انجام بدید.

بدی هاش:
- نداشتن parititon و اسکیل نشدن میلیونی.

بنظرتون این تریدآف منطقیه برای بیزنسی که نیاز میلیونی نداره؟
خیلیا میگن postgresql درواقع به بلوغ نرسیده برای اینکه queue باشه. من اسمشو بلوغ نمیذارم. خیلی کانسپت هایی که تو کافکا داریم صرفا برای اینکه مشکل دو ژنرال تا حدی حل شه. مثل transaction زدن, مثل acknowledge کردن, مثل ... .یعنی مشکلات پیچیده ای به وجود اومده, چون سیستم پیچیده شده. سیستم پیچیده شده, چون برنامه نویس فکر میکرده شاید روزی بخوام میلیونی اسکیل کنه. پس شما درگیر مشکلاتی هستین که نباید میشدین واقعا.

@PyBackendHub

Читать полностью…

چیزی که میگم ممکنه راحت بنظر برسه
یا شاید هم تابلو.
ولی تا وقتی که ویدیو رو نبینید متوجه نمیشید دقیقا این طرز فکر چیه. خیلیم سخته که بخوام تو ۲۰۰ کلمه خلاصش کنم.
تو این اسکرین شات شما محاسبات بسیار ساده ای رو میبینید (که ممکنه بنظرتون خیلی سخت و پیچیده باشه ولی نیست) که داره حساب میکنه این کدش چقدر mathematic آپریشن انجام داده. و طبق سی پی یویی که داره چقدر میتونه کدش سریع بشه. مینیموم ترین سرعت رو کاغذ چیه؟ و چه تفاوتی با عمل داره.

این ویدیو به شما فقط مواردی که بهتون گفتم یاد نمیده, بهتون سخت افزار یاد میده, بهتون دانش کارکرد CPU و رم یاد میده, بهتون یک دید با زاویه کاملا متفاوتی میده که احتمالا نداشتین. (شخصا که نداشتم)

خلاصه ببینید ضرر نمیکنید 😁 ارزش ۲ ساعت رو واقعا داره.
@PyBackendHub

Читать полностью…

یک کدی دارین که خیلی کنده. تیکت اومده که کاربر ها راضی نیستن از کندی این اون قسمت.
چطوری بهترش میکنید؟ مرحله هایی که طی میکنید برای بهتر کردن پرفومنس یک کد رو کامنت کنید.

@PyBackendHub

Читать полностью…

دو سری نکته اضافه کنم:

۱. دوستان این مثاله طبیعتا تو ۲۰ خط کد نمیتونم اون مشکل extend بیزنس رو بیارم. شما فرض کنید هزاران شیپ دارین، هزاران فیچر دوره این شیپ دارین، ایا یادتون خواهد بود که یک جایی یک constraint ای دارین که یک شکل فقط‌ دو بعدی میتونه باشه با این بیس کلس؟
اون زمانی کد که Shape زده شد فرض کنید ۱۰ سال‌پیش بوده، کسی نمیدونسته قراره یک پرینتر سه بعدی بیاد و ما اشکال سه بعدی هم پرینت کنیم.

۲. اگه راه حل مچ کیس رو بریم، Shape دیگه وجود نخواهد داشت. صرفا چون دو اسکرین شات نشه جدا نکردم.

تو لایوی که میذارم، یکی از چیزایی که نشون میدم همینه که چطوری از تایپ سیستم استفاده کنیم برای نشون دادن constraint های بیزنس ولایه بیزنس

@PyBackendHub

Читать полностью…

توضیح پست بعدی...

@PyBackendhub

Читать полностью…

یک نکته بگم که برداشت اشتباه نشه از این پست من. من با این پست نمیخواستم این پیام رو به مخاطب بدم که حتما باید بری یک پروژه واقعی اوپن سورس استارت بزنی. میخواستم درک کنید چرا دانش theory برای گرفتن شغل میتونه کافی نباشه و چرا شرکتا همیشه ترجیحشون با کسیه که سابقه کاری داره. و درک کنید کد زدن برای بیزنس یک اسکیله که اگه برای بیزنسی کد نزدی قطعا نداریش.
امیربهادر راه های دیگه ای هم اشاره کرد مثل کاره فریلنسری. یا ...

نکته خیلی مهم اینه که وقتی من دارم رزومتون رو میخونم, نبینم صرفا دو پروژه فروشگاهی زدید و جز این چیزه دیگه ای نیست تو رزومتون. اون وایب problem solver رو باید من بدید. ممکنه هم با همچین رزومه ای کار پیدا کنید ولی احتمالش کمتره.
برای پیدا کردن کار بنظره من ۳ فاکتور دخیله: ۱. لوکیشن خوب. ۲. میزانی که اپلای میکنید. ۳. کیفیت رزومه. لوکیشن ممکنه دسته خودتون نباشه, ولی اون ۲ تای دیگه هست.

@PyBackendHub

Читать полностью…

دیشب تو گروه بحث بود که من اینترن هستم و چیکار کنم که شغل پیدا کنم یا رزومه‌ام بیشتر دیده بشه. تو پیوی هم خیلیا سوال می‌پرسن که چطور بدون تجربه کاری اولین شغلشون رو بگیرن. ببین، همه شرکتا دنبال کسی می‌گردن که واقعاً یک مهارت رو بلده. حالا شاید بگی من ۴ سال دانشگاه رفتم، ۱۰ تا پروژه تمرینی هم تو گیت‌هاب گذاشتم، پس چرا قبولم نمی‌کنن؟ ولی باید بدونی که تعریف "بلد بودن" اینجا متفاوته.

یه پروژه مثل فروشگاه اینترنتی شاید کمک کنه چیزای پایه‌ای یاد بگیری، ولی نمیشه گفت واقعاً بلدی. چرا؟ چون یه نرم‌افزار ساده ساختی که خیلی پیچیده نیست، یه مشکلی رو حل نکردی، شاید فقط چندتا کد رو کپی پیست کردی. "بلد بودن" یعنی این که بتونی از دانشت به‌صورت عملی استفاده کنی و یه مشکل واقعی رو حل کنی، اونم جوری که بفهمی چه اتفاقی داره میفته. این اتفاق تو پروژه‌های تمرینی که یه بار می‌زنی و می‌ذاریش کنار، نمیفته.

مثلاً یه بازی بود قدیما تو ایران به اسم "تراوین". یه نقشه ۴۰۰ در ۴۰۰ داشت (مختصات منفی هم داشت) یعنی ۱۶۰۰۰ خونه. هر کاربر که ثبت‌نام می‌کرد، یه خونه تو نقشه می‌گرفت که می‌شد دهکده اصلیش. اولین شرط بازی این بود که دو دهکده نمی‌تونن تو یه مختصات باشن. خب، اینجا می‌تونستی یه تیبل با ۱۶۰۰۰ خونه بسازی و هر بار که کاربر ثبت‌نام کرد، یه مختصات خالی بهش بدی. به این روش میگن whitenoise sampling
تا اینجا پروژه تمرینی تموم میشه. ولی پیچیدگی از اینجا شروع میشه که بیزنس متوجه میشه کاربرا تو کل نقشه پخش شدن، بعضیا چسبیدن به هم، بعضیا دورن. حالا بیزنس میگه برای بیشتر کردن هیجان بازی، باید کاربرا رو نزدیک هم نگه داری. برای همین، مثلاً به جای ۱۶۰۰۰ خونه، ۴۰۰ خونه مرکزی رو در نظر می‌گیری و وقتی نصفش پر شد، میری سراغ ۱۶۰۰ خونه. به این روش میگن progressive sampling.
مشکل بعدی اینه که کاربرا خیلی بهم چسبیدن و این باعث میشه هیجان بازی زیادی زیاد شه و اول بازی همه به هم حمله کنن، که این خودش باعث میشه خیلیا همون اول بازی رو ول کنن. حالا بیزنس می‌خواد یه فاصله حداقلی بین دهکده‌ها بذاری. اینجا به روش blue sampling می‌رسی.

می‌بینی؟ یه سیستم ساده چطور با دوتا نیاز بیزنسی که اول مشخص نبود، پیچیده شد؟ این مثال رو زدم که بگم یه پروژه مثل فروشگاه زدن اصلاً چشمگیر نیست. با همونم شاید شغل بگیری، ولی اگه می‌خوای سریع‌تر شغل پیدا کنی، برو یه پروژه استارت بزن که واقعاً به دردت بخوره و یه مشکلی که داری رو حل کنه.
پس من میگم طبق قانون gall سیستم complex ای که کار کنه به دنیا نمیاد, بلکه سیستم ساده ای بود که کار میکرد و به سیستم complex بلوغ پیدا کرده. یک مقاله خیلی قشنگ راجب همین قانون.
مثال؟ یه نگاه به گیت‌هاب من بنداز. همه پروژه‌هام اینطوریه. از لینکدین کراولر گرفته تا کلودفلیر کراولر و aioclock. همه برای این ساخته شدن که یه مشکلی که داشتم رو حل کنن.

@PyBackendHub

Читать полностью…

یک راهنمایی بزرگ:‌لاجیک کد مشکل نداره.
خروجی کنسول اینه:

Ma: Hirad
Hir: Hirad

در صورتی که باید Ma: Mani و Hir: Hirad باشه. چرا؟

@PyBackendHub

Читать полностью…

۲۷۰ هزار خط جیسون رو تو ۴ ثانیه فایل جنریت کرد.
برای همچین کاری از gpt استفاده نکنید بهتره چون:

۱. امکان خطا خیلی زیاده. جی پی تی یک LLM هست نمیتونه <فکر> کنه صرفا پترن مچ میکنه و یک ضرب و تقسیم ساده هم اشتباه میکنه. پس هیچوقت برای کد جنریت کردن ازش استفاده نکنید.

۲. سواگر یا redoc یا خانواده این ابزار ها همه از openapi استفاده میکنن. openapi یک Specification هست برای نوشتن api های rest. و داره از json schema استفاده میکنه. جیسون اسکیما هم دوباره یک Specification هست که تایپ ولیدیشن رو بین همه زبون ها استاندارد کرده. این ابزار AI نیست. چون تعداد حالت محدوده, و جیسون مشخصه چه چیزایی میتونه داخلش باشه پس میتونه به صورت static درست ‍parse کنه.
اگه از جیسون پایندنتیک بسازین احتمال اینکه یک خروجی باشه که تو اون مثالتون نبوده هست. ولی اگه از json schema پایندنتیک بسازین, دیگه امکان نداره اشتباه parse کنید.

@PyBackendHub

Читать полностью…

مدیرها، بی‌خیال تیم‌هاتون بشید! لازم نیست کارمندها رو مثل بچه‌هایی که نیاز به مراقبت دائم دارن، کنترل کنید.

اونا نباید برای داشتن زندگی شخصی بیرون از کار معذرت‌خواهی کنن.
به تیم‌تون اعتماد کنید که کار رو تحویل بدن. اینجوری یه محیط مثبت و مولد می‌سازید که همه می‌تونن توش رشد کنن.
استخدام افراد درست فقط شروع کاره. جادوی واقعی زمانی اتفاق می‌افته که بهشون اعتماد کنید و قدرت بدید.
اعتماد یعنی اینکه به تیم‌تون آزادی بدید که کارشون رو بدون دخالت مستقیم شما مدیریت کنن. این نشون می‌ده که بهشون به‌عنوان آدم‌های بالغی که می‌تونن هم زندگی کاری و هم زندگی شخصی‌شون رو مدیریت کنن، احترام می‌ذارید.
این فقط محدود به مرخصی و تعطیلات نیست.
بحث اینه که یه فرهنگ بسازید که آدم‌ها توش احساس کنن می‌تونن کارشون رو به بهترین شکل ممکن انجام بدن - چه توی دفتر باشن، چه از راه دور کار کنن، یا حتی وسط روز کارهای شخصی‌شون رو انجام بدن.
تمرکز باید روی نتیجه باشه، نه “micromanagement”.
Micromanagement خلاقیت رو می‌کشه و انگیزه رو نابود می‌کنه.
اعتماد، برعکس، آدم‌ها رو به بهترین عملکردشون تشویق می‌کنه.
وقتی به تیم‌تون مالکیت کارهاشون رو می‌دید و بهشون فضا می‌دید که موفق بشن، می‌بینید که چطور رشد می‌کنن.

چطور این فرهنگ رو بسازیم:
- افراد درست رو استخدام کنید: مطمئن شید که مهارت دارن و با ارزش‌های شرکت هم‌سو هستن.
- به تیم‌تون اعتماد کنید: بذارید مالک کارهاشون باشن و خودتون رو از دخالت مستقیم دور نگه دارید.
- آزادی بدید: بهشون اجازه بدید تصمیم بگیرن و ابزارهای لازم رو فراهم کنید.
- رهبران قوی تربیت کنید: مدیرها رو طوری آموزش بدید که بتونن تیم‌ها رو حمایت کنن بدون اینکه کنترل کنن.

- ارتباطات رو باز نگه دارید: فضایی ایجاد کنید که آدم‌ها احساس امنیت کنن و بتونن ایده‌ها و فیدبک‌هاشون رو راحت به اشتراک بذارن.
- موفقیت‌ها رو جشن بگیرید: دستاوردها رو بشناسید و انگیزه رو بالا نگه دارید.
- از تعادل بین کار و زندگی حمایت کنید: به تعادل سالم تشویق کنید تا رفاه و بهره‌وری بهتر بشه.
♻️ Neha K Puri

@PyBackendHub

Читать полностью…

یک مقاله خیلی خوب برای توضیح دادن این میم:
https://avestura.dev/blog/explaining-the-postgres-meme

@PyBackendHub

Читать полностью…

حق!
ایلان ماسک یک حرف قشنگ زد، گفت هرچی قدم ها کوچیک تر باشه و سریعتر باشه، بهتره تا قدم های بلند تر. این موضوع چه استارت آپ چه FAANG صدق میکنه. حالا چرا؟
۳ نقطه تصور کنید تو یک بردار مختصات، اولی میشه software requirement. چیزی که دارید کد میزنیدش. دومی میشه business requirement. چیزی که بیزنس گفته نیاز هست بهش. و سومی میشه user needs. چیزی که واقعا یوزر‌ نیاز داره.

این ۳ نقطه تو واقعیت نزدیک بهم نیستن. چون بیزنس هیچوقت درک ۱۰۰درصدی از نیاز کاربر نداره، و نرم افزار سعی میکنه چیزی که بیزنس گفته رو پیاده کنه. نیاز انسان دائم در حال تغییره، پس نقطه سوم در حال تغییره رو نمودار. حالا منطقیه شما یک مسیر خیلی بزرگ رو برید؟ اون موقع میبینید دیگه اون نیازمندی وجود نداره وقتی به مرحله shipment رسیدین! ولی‌قدم هاتونو هرچی کوچیک و سریعتر کنید اون نقطه در حال حرکت رو بهش بهش نزدیک تر میشید و دنبالش میکنید.

@PyBackendHub

Читать полностью…

تلگرام و لینکدین شده پر از پست های GPT و LLM. خیلی وقتا حتی‌ پستی که نوشتن رو نمیخونن. این مورد تو رزومه هم خیلییی دیده میشه!!!
این پستو ببینید،
نوشته مزایاش بهبود عملکرد، و maintainability عه. نگه داری و توسعه اش راحت تره.
بعد تو چالش هاش نوشته پیچیدست و نگه داریش سخته ؟؟؟!!!.

الان این متن پارادوکسه 😁
گرچه پرفومنس قطعا بهتر نمیشه، و قطعا افت میکنه. چون خیلی وقتا یک چیزه کمی از اون کوئری میخواین، ولی مجبورین چون اینترفیسش هست کلشو بگیرین. و یا ممکنه تو گرفتن یک کوئری، جوین هایی بخوره یا مراحلی انجام شه که اصلا نیاز نبوده تو اون یوزکیسی که دارین reuse میکنید از اون کوئری اینترفیس

@PyBackendHub

Читать полностью…

یکی از بهترین بیلد بک اند هایی که میتونید تو پروژتون داشته باشین hatchling هست.
خیلی کارای خوب و زیادی انجام میده براتون که تو یک پست نمیگنجه بخوام کلشو توضیح بدم.

احتمالا از پکیج منیجر استفاده میکنید مثل uv یا poetry یا pdm یا ... . اگه استفاده نمیکنید, حتما بکنید 😅

برای استفاده از hatchling کافیه تو pyprojectتون اینو بذارین

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

بعد مثلا سورس کدتون داخل یک دایرکتوری به اسم src هست. که همه ایمپورت هاتون این شکله:
from src.models import User

اونوقت کافیه اینم اضافه کنید به پای پروجکت

[tool.hatch.build.targets.wheel]
packages = ["src"]

@PyBackendHub

Читать полностью…

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

اگه کلشو وقت نکردید ببینید دقیقه ای که گذاشتم رو ببینید 😂😂
https://www.youtube.com/watch?v=WiPp9YEBV0Q&amp;t=1719s

تو این ویدیو شما ted ts'o رو میبینید که مثل یک بچه داره با دیدگاه های غیر تکنیکال داره حمله میکنه به فردی که داره پرزنت میکنه. بعضی نظراتش البته کاملا تکنیکاله ولی عمدتا شما ویدیو رو ببینید جو منفی و بد رو از این فرد میگیرین.

حالا ایشون کیه؟ ایشون maintainer و author بخش های معروفی از لینوکسه. مثل
ext file-system
/dev/random

خلاصه مهم نیست چقدر یک آدم تکنیکالی خفن و خوبه, در نهایت یک آدمه. و آدما میتونن چهره جالبی رو از خودشون نشون ندن یا مزخرف بگن. از کسی بت نسازید.

@PyBackendHub

Читать полностью…

توضیح در پست بعدی...

Читать полностью…

۷۲ کامنت گذاشته شده تا این لحظه، اکثرش هم درسته اشتباه نیست. مثل بحث observability، پروفایلینگ، بررسی خودت تیکت و شرایط کاربر، و … . منکر درست بودن اینا نیستم اصلا. یک سری کامنت غلط هم بود (از نظره من)، ولی یک چیزه خیلی خیلی ساده جا موند! کسی نگفت من میرم کدو بخونم ببینم چیکار میکنه و چیکار باید میکرده😅 ساده فکر کردن خیلی سخته😁

ببینید اگه میخواین یک کد رو پرفومنسشو بهتر کنید، اولین قدم آپتیمایز کردن اینه که شما یک کاغذ برداری، و این ۳ فلو اجرا رو بکشی (execution flow):
۱. حداقل فلویی که نیازه طی شه برای انجام اون کار
۲. بعد یک بررسی ساده و سریع، فلویی که فکر میکنی اتفاق میفته
۳. با دیباگر کدو ران کنی و جامپ کنی، و واقعا فلویی که اتفاق میفته

در کمال ناباوری، هیچوقت این ۳ تا نزدیک هم نیستن! 😅 وقتی این ۳ فلو رو داری، میتونی دقیقا تخمین بزنی که چقدر میتونی latency یک کد رو کم کنی. چقدر میتونی سریعترش کنی. با یک ضرب و تقسیم این عدد خیلی راحت به دست میاد. مراحل اضافه هم میتونی حذف کنی و تصمیم بگیری کجا رو ریفکتور کنی.
ببینید تو پروفایلینگ شما hotloop برنامتون رو پیدا میکنید، و اپتمایز میکنید. ولی اگه ۱۰۰ قدم ریز دارین برمیدارین که لازم نیست، و یک قدم بلند که لازمه انجام شه، پروفایلر به شما میگه اون قدم بلند رو آپتمایز کن. که لزوما ممکنه بهترین راه حل نباشه.

ویدیو زیر رو توصیه میکنم ببینید. ۳ ساعته، ولی یک ساعت اخرش پرسش پاسخه. یکی از قشنگ ترین ویدیو های tech هست که دیدم. کلشو یک شبه تموم کردم😅 ساعت ۹ شروع کردم دیدن، ۱۲ تموم شد!
https://www.youtube.com/watch?v=Ge3aKEmZcqY

این ویدیو شما رو قانع خواهد کرد:

۱ نرم افزار ها به شدت خیلی عجیبی کند هستند. همه نرم افزار ها! و سخت افزار خیلی سریعتر از چیزی هستن که میتونید تصور کنید.
۲. زبون و الگوریتم قطعا تاثیر گذار هست تو سرعت، ولی نه خیلی! چیزی که تاثیر گذار ترین عامله طرز فکر کسیه که داره یک کدی رو مینویسه.
۳. پرفومنس و readability و ساده بودن کد، دو نقطه متقابل نیستن!
۴. سرعت و latency اجرا شدن کد، تو هر بیزنسی مهمه.

@PyBackendHub

Читать полностью…

نسخه جدید CfCrawler منتشر شد. همون کتابخونه ای که تو این پست راجبش حرف زده بودم.

تغییرات این نسخه:
- Make dependency to fake useragent optional
- Implement new backend support for user agent factory pool
- Implement default simple user agent pool
Improve code quality
- Fix issue with rotating user agent not changing TLS fingerprint respectively
- Fix issue with ignoring httpx transport on httpx client constructor -> now it patch the passed transport instead of ignoring it, and if not passed default to a simple transport.

لینک گیتهاب

اگه این پست و لایبری براتون مفید بود، خوشحال می‌شم اگه بهش استار بدید. این کار به من انگیزه بیشتری برای توسعه و بهبود فریم‌ورک های اوپن سورس میده. از حمایت‌تون خیلی ممنونم 🙂 🙏

@PyBackendHub

Читать полностью…

یک مشکلی که اکثر برنامه نویس ها دارن اینه که موقع extend کردن یک سیستم پیچیده ای اون رو break میکنن. چون یک کیسی وجود داشت که یادشون رفت هندل کنند یا بهش فکر نکرده بودن. راه حلش چیه؟
یک سیستم ساده رو تصور کنید، مثل یک پرینتر دو بعدی. شما یک سری shape دارین که میخواین دو بعدی پرینتشون کنید. بیایید دو تا راه مختلف رو بررسی کنیم.
راه اول: فرض کنید که یک Base یا کلاس پایه داریم که تمام اشکال از اون ارث‌بری می‌کنن. مثلا یک کلاس Shape داریم که Circle و Square ازش ارث‌بری می‌کنن. حالا فرض کنید که به جای دو تا shape، صد تا shape داشتیم. با نگاه کردن به کد، می‌فهمیدیم که یک شیء از نوع Shape داره پرینت میشه، ولی دقیقاً نمیدونیم چی. فقط میدونیم که یک چیزی که abstract شده و یک shape هست داره پرینت میشه. این یعنی تایپ سیستم داره بهمون میگه "خب، یه شکلی هست، ولی من نمیدونم دقیقا چی." مشکلی که داره اینه که فکر کنید من یک معکب بخوام بسازم. و مثلا ۱۰۰۰ تا shape داشته باشم و یک سورس کد خیلی گنده. آیا مکعب دو بعدی پرینت میشه؟ نه. پس وقتی دارم ارث بری میکنم باید کل وابستگی همه کدم به Shape رو تو ذهنم داشته باشم و احتمال زیاد یک چیزی رو break میکنم. تو این مثال کد بالا, اگه ارث بری کنم و مکعب رو اضافه کنم فانکشن پرینت دو بعدی break میشه.
راه دوم: بیایید به جای استفاده از یک Base کلاس، از تایپ‌های مشخص‌تر استفاده کنیم. اینجا دقیقاً میدونیم که چه حالاتی در زمان اجرا داریم. مثلا، کد ما مشخص می‌کنه که یا Circle داریم یا Square. هیچ چیزی به صورت abstract یا مبهم نیست. خوبیش اینه که وقتی کد رو extend می‌کنی، نمیتونی ناخواسته جایی از سیستم رو بشکنی. چون وقتی یک شیء جدید مثلا مکعب که ۳ بعدی هست رو اضافه می‌کنی به اون Union که تصویر, اون وقت تایپ چکر تو خط آخر به شما میگه که مکعب هندل نشده و Never نیست.
بنابراین باعث میشه که موقع extend کردن، کل کدت قرمز بشه. خوبیش اینه که نمی‌تونی چیزی رو تصادفی و غیرعمدی خراب کنی. بدیش اینه که باید بری و همه جا رو درست کنی و به همه چیز فکر کنی.یک بدی دیگه هم داره که فقط شامل حال library ها میشه نه کد های بیزنس. دلیلشو اگه حدس زدید کامنت کنید 🙂
خلاصه، این روش به وضوح و پیشگیری از خطا کمک می‌کنه، اما در عین حال، سخت‌گیرتره و نیاز به توجه بیشتر داره. به این روش میگن استفاده از تایپ سیستم برای present کردن لایه بیزنستون.

@PyBackendHub

Читать полностью…

دوستان خواهشا پیوی من سوال برنامه نویسی و جنرال نپرسید.

/channel/PythonFellow
عضو گروه بشین، من همیشه معمولا پاسخ میدم. بقیه هم میدن، سوال ممکنه برای شما باشه ولی بقیه هم میتونن استفاده کنند جواب بدن و نظره من ممکنه bias باشه. بحث بهتره جمعی باشه تا دو نفره.


پیوی زمانی بپرسید که سوالتون رو نمیخواین تو جمع مطرح کنید به دلایل خیلی شخصی.

@PyBackendHub

Читать полностью…

خیلیا سوال میپرسن موقعیت کاراموز و جونیور گیر نمیاد، چطور استخدام بشیم پس

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

اینجا مانی یکسری توضیحات داده که چرا پروژه های ساده نمیتونن مارو استخدام کنن :

/channel/PyBackEndHub/1109

دوست عزیز وقتی میخوای پروژه بزنی، نگا نکن چه توانایی داری، تو باید خودت رشد بدی، فراتر از توانایی هات تصمیم بگیر، برنامه نویسی که به چالش نخوره ، کرم شب تابه با لامپ سوخته (این چه مثالیه، حداقل زنبور بی عسل رو‌ میگفتی)

حتی با یک پروژه هم میتونید استخدام بشید، حتی میتونید استخدام کنید افرادی رو که براتون کار کنن :)

من هنوز از پروژه های ۵-۶ سال پیشم درامد دارم، اگر سپنتا خاموش نمیکردم از پروژه ده سال پیشمم هنوز درامد میتونستم داشته باشم

@SEYED_BAX

Читать полностью…

https://www.pulumi.com/

یک Iac هست که خیلی جذبش شدم برای یاد گرفتنش.
به جای اینکه yaml بنویسید تو یک زبون برنامه نویسی دلخواهتون مینویسید. و قابلیت های خیلی خوبی داره.

@PyBackendHub

Читать полностью…