Step 1:
pip install -U cookiecutter

Step 2:
cookiecutter gh:lnxpy/cookiecutter-pyaction

یا

Step 1:
pip install pyaction

Step 2:
pyaction init


Solution 1: ❤️
Solution 2: 🔥

یک بخشی از تستای همین لایبری:

معمولا تستامو نمیدم ai بنویسه.
دلیلش هم اینه که بهترین کسی که تست مینویسه همون کسیه که کد رو زده. کاره لایبری من تو همین ۳ خط خلاصه میشه و مهم ترین تستمم همینه. حالا ai میرفت ۲۰ تا تست الکی مینوشت که ۱۹ تاش به درد نمیخورد واقعا و maintain کد رو سخت تر میکرد و انعطاف پذیری رو کمتر میکرد.

پ.ن:‌arg تایپ مرورگر optional هست.

@ManiFoldsPython

Readability vs Performance?!

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

00:00:00 آغازین

00:00:32 برنامه‌نویسی چطوری شروع کنیم بهتره؟ بریم دبیرستان و دانشگاه برنامه‌نویسی بخونیم یا خودآموز پیش بریم؟ سابقه کار چجوری جور کنیم برای خودمون؟

00:25:42 حالا بعد از دانشگاه چطوری وارد بازار کار بشیم؟ چه کارهایی باید انجام بدیم؟

00:44:55 بریم سراغ شاخه بک‌اند. چه چیزهایی رو یادبگیریم و چیکارهایی کنیم تا از جونیور به میدلول برسیم؟

1:09:47 از میدلول به سینیور بک‌اند

1:22:56 نکته و حرف‌های پایانی
1:27:27 موسیقی پایانی ( آقای ماروین از گروه او و دوستانش )

PodCast: @CodeNaline
Mani : @ManiFoldsPython
Boby: @BobyDotCloud
Torham: @TorhamDevCH

آیندمون اگه تصویر بود:

سلنیوم رو بندازین دور و از playwright استفاده کنید بلکه به راه راست هدایت شوید!

Playwright: https://playwright.dev/python/

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

Ah shit.. here we go again. 🚬 🌱

#GTA6

همیشه در پوشه فونت قلبمون، یاد و خاطرت باقی خواهد موند. 🖤

می‌خوام ترجمه پارسی داک پای‌اکشن رو هم اضافه کنم. اگه کسی مایل بود، می‌تونه اینجا اعلام آمادگی کنه تا باهم روش کار کنیم. ❤️

(کلا چندتا داکیومنت بیشتر نیست)

https://github.com/lnxpy/cookiecutter-pyaction/issues/21

تلاشش ستودنیه!

دوستانی که میپرسن چطور من sql یاد گرفتم:

۱. اولا هیچ query رو اخیرا دیگه رو اول تو orm به صورت کد نمینویسم مگه اینکه یک چیز خیلی ابتدایی باشه. اول همیشه با دیتابیس مینویسم بعد میام رو orm معادلشو مینویسم. این عادتو حتما ترک بدین و به محیط دیتابیس عادت کنید.

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

۳. همین query هایی که طی روز مینویسید تلاش کنید بهینه و با ۱ هیت بنویسید. با ۱ هیت نوشتن دلیل بر این نمیشه که query بهینه شد. explain و analyze رو بزنید ببینید چه اتفاقی داره میفته. با مفاهیم داخل دیتابیس آشنا باشین. بدونید cost estimate و execution plan وactual time و rows and width و buffers چیه. صرفا سریع ران شدن هم دلیل بر آپتیمایز بودن یک query نیست. ممکنه مموری خیلی زیادی مصرف کنه. پس متریک های دیتابیس رو یاد بگیرین. و کار کردن باهاش رو. مثل یک زمین بازی میمونه هرچی بیشتر توش بازی کنید بیشتر یاد میگیرین.

آیا مهمه؟
صد در صد 🙂 اخیرا دیدم تو community پایتون خیلی مانور میرن رو اینکه پایتون رو بشدت دیپ شن. بد نیستا ولی اولویت بندی کنید از بقیه چیزا غافل نشید. خیلیا که با orm کار میکنن اگه ۵ تا سوال sql ازشون بپرسن بلد نیستن چون تو عمرشون زیاد تو دیتابیس نچرخیدن و سرو کله نزدن.

@ManiFoldsPython

یه جمله خیلی بامسما در کتاب Clean Code in Python هست که میگه:

Having maintainable software is not about anticipating future requirements (do not do futurology!)

ترجمه: داشتن یه نرم‌افزار قابل‌نگهداری به معنی پیش‌بینی نیازمندی‌های آینده نیست. (آینده‌پژوهی نکنید!)

اینجا "پیش‌بینی" به معنی تخصیص انرژی و زمان واسه ساخت یه بستر برای توسعه ساده‌تر در آینده با توجه به نیازمندی‌هایی هست که بعدها ممکنه بوجود بیان.

منظور اینه که بجای اینکه بیایم ذهنیت، معماری و دیزاین رو محدود به آینده کنیم، سعی کنیم نیازمندی‌های فعلی رو برطرف کنیم.

یه مثال کاربردی می‌زنم تا درک این قضیه ساده‌تر شه. فرض کنید شما یه Shop طراحی کردید و فقط یه متد پرداخت دارید و اونم PayPal هست. درحالی که دارید کلاس PayPal رو طراحی می‌کنید، این فکر به ذهنتون خطور می‌کنه که شاید بعدها متد پرداخت Stripe هم به سیستم اضافه شد. اونوقت من باید یه کلاس عین PayPal واسه Stripe درست کنم.. چرا از همین الان یه Base Class درست نکنم و PayPal و Stripe از اون بیس‌کلس ارثبری نکنن؟

موضوع اینه که هنوز نه به باره.. نه به داره.. استرایپ کو؟! داری عملا از دیزاین‌پترنی استفاده می‌کنی که اصلا نیازی بهش نداری. بله. درسته. این یه دیزاین OOP پرفکت هست و بهتره که همچین حرکتی رو بزنی ولی آیا الان؟!

اینجاست که Over-engineering کار دست آدم می‌ده. بنظرم این دو موضوع Overengineering و Overthinking در کنار هم میان. تمرکزتون رو بذارید روی نیازمندی‌های فعلی و سعی کنید سلوشن خوب برای الان بدید.. بعدا با تغییر نیازمندی‌ها، می‌تونید سراغ دیزاین‌پترن‌ها و متدلوژی‌ها و معماری‌های پیچیده‌تر هم برید!

خودم شخصا این قضیه "بیش از حد فکر کردن به مهندسی پروژه" باعث شده یه سری ایده‌ها از ذهنم بپرن.. یه‌سری از کارها رو (چون سلوشن جامعی به ذهنم نمی‌رسید) به تعویق بندازم.. یه سری پروژه‌ها رو اصلا شروع نکنم و... دلیلش اینه که سعی داشتم تا آینده خیلی دور پروژه رو توی ذهن و روی کاغذ ترسیم کنم و این خیلی اشتباه هست.

یه سیب که از درختی میوفته، تا برسه به زمین، چند دور می‌چرخه.

و اینکه درمقابل تغییرات، گارد نگیریم. کدی که کار می‌کنه، (صرفا) کار می‌کنه و "صرفا کارکردن" خوب نیست.

Async meme 😂

همیشه ساده فکر کردن هنره. من با صدرا کاملا موافقم. همیشه نباید خیلی آینده نگر و کمالگرا باشیم. مثلا اگه اپ چت تحت وب داریم مینویسیم دیگه نباید دیزاین رو طوری کنیم که <ممکنه در آینده بخوایم گوشی و نوتیفیکشن هم ساپوت کنیم> . یعنی این assumption هیچوقت نباید از برنامه نویس بیاد. این احمقانه ترین کاره چون کد بیشتر میزنید در صورتی که بیزنس و پروداکت اصلا بهش احتیاج نداشت!

۱. خب من چیکار میکردم؟ تو سناریو اول کلا schedule نمیکردم! به جاش همون لحظه ای که schedule کرده پیام رو داخل دیتابیس میساختم ولی یک فیلد میذاشتم با display_at به زمان آینده که توسط یوزر تعیین شده. و وقتی بقیه کلاینت ها (تو همون گروه تلگرامی) درخواست میفرستن که محتوا رو ببینن فقط محتوایی که display_atشون کمتر مساوی زمان حال بود رو نشون میدادم.
that's it!
نه بروکر نیازه. نه استریم. نه event driven architecture
من تونستم به همون هدفی که requirement ام بوده برسم. که بقیه یوزر ها ببینن پیامو. همیشه وقتی requirement مینوسید رو how تمرکز نکنید. رو what تمرکز کنید. اگه requirement این بود که طرف schedule کنه اونوقت اون requirement احتمالا احمقانه هست چون داره رو نحوه پیاده سازی دخالت میکنه.


@ManiFoldsPython