Readability vs Performance?!

سوال خیلی قشنگیه، جواب شما چیه؟ جواب من:
من میگم هرچی پروداکت بگه! ولی به طور کلی کدای readable باتل نک نیستن, ولی کدایی که میخواین خیلی high performance باشن قطعا readable نیستن

و یک study نشون داده اپلیکیشن ها ۸۰درصد مواقع اپلیکیشنمون منتظره IO هستن حتی با وجود اینکه parallel هستن (مثلا میخوان یک response بدن بیرون خب باید وایسن جواب query بیاد) پس optimize کردن IO خیلی بهتره تا micro-optimization تسکای cpu bound

و وقتی گفتم پروداکت یعنی همه اینا بستگی داره همه اینا کجا کدو بذاریم… مثلا ممکنه داریم یک سیستم api rate limit طراحی میکنیم که اگه کدو زشت کنیم یک دفعه پرفومنسو دو برابر کنه مثلا و هزینه نگه داری همه سرویسای restرو نصف کنه.. خب اونجا قطعا میرم micro optimization رو ترجیح میدم..

@ManiFoldsPython

یعنی متنفرم از گروه هایی که ۵ دقیقه تایمر میندازه بین هر پیام تو تلگرام تو گروهش…
قشنگ توهین به شعور مخاطبه :)

ادم میخواد جواب ۲ نفرو بده بیخیال میشه….

دیشب صدرا یک سوال خوب پرسید, امشب نوبت منه‌ که یک سوال میلیون دلاری بپرسم :)) خودتونو تو این شرایط قرار بدین:
یک conflict دارین با تصمیم گیرنده. حالا تیم لید باشه یا هرکی کاری ندارم. فکر میکنید که شما روشتون اصولی تره و درست تره ولی اون موافق نیست و میگه <فعلا نیازی نیست> شرایطی که شاید خیلیاتون تو ایران بهش برخوردین.

مثلا:‌راجب تست نویسی. بیشتر تست کنیم, کدو ریفکتور کنیم بهتر شه. تمیز تر شه. یا چیزای این قبیلی.
چطور conflictتون رو حل میکنید؟

هنر رفع conflict مهم ترین سافت اسکیله به نظره من!

@ManiFoldsPython

یک سری نظرا رو شنیدم. من نظره خودمو میگم که بیشتر بحث کنیم, ببینید وقتی conflict وجود داره چند اشتباه ممکنه دو طرف بکنند که بهتره بررسیشون کنیم:

۱. اینپوت شما همیشه باید خیلی با ارزش باشه. با ارزش بودن به این دلیل نیست که حتما قبول شه. به این دلیله که شنیده شه و حتی راجبش بحث شه یا جلسه گذاشته شه. غیر این باشه محیطی نیست که توش بتونید پیشرفت کنید. ممکنه همه input هاتونم ریجکت شه و این موضوعو نباید سوءبرداشت شخصی ازش داشته باشین. پس اگه جای تصمیم گیرنده هستین این حس با ارزش بودن اینپوت و شنیدنشو منتقل کنید. فیدبک ها همیشه باعث بهتر شدن یک سیستم میشن.

۲. همیشه فکر میکنن ۲ تا نقطه مقابل هم وجود داره تو conflict در صورتی که اصلا اینطور نیست. مثلا کارفرما میگه اقا من این پروداکتو باید تا فلان روز برسونم سریع کدشو بزن. شمام میگی نه ریفکتور میخواد اصولی نیست. منتهی تو این سناریو یک راه حل سومی هست: که شما با اون فرد بشینی مذاکره کنی و بحث کنی. ممکنه یک نقطه وسط برسین. در درجه اول باید درک کنید طرف مقابل چی میگه. در درجه دوم راهکار خودتونو به نحوی بچرخونید که با هدف اون همسو باشه. مثلا این arguement اش این میشه که اقا من باید رو هر فیچر جدید دستی تست کنم که کار میکنه. من argue میکنم که اگه تست خودکار بنویسم وقت کمتری مصرف میکنم. پس نظرت چیه شرط ببندیم برای این فیچر جدید که من سریعتر میرسونم با داشتن تست؟‌ سرعت توسعه منو بیشتر میکنه. یا مثلا بگین اقا من این قسمت جدیدی که دارم اضافه میکنم رو تمیز کد میزنم. کاری ندارم به بقیه. و کارمو هم سریع تر میرسونم. ممکنه کد consistent نشه و یک دفعه خیلی متفاوت شه ولی بهترین راه کاره. اینطوری هم کارو سریع میرسونم هم کم کم ریفکتور میشه با فیچر های جدید تری که اضافه میکنیم به این پروژه.

۳. سطح علمی طرف مقابل رو در نظر نمیگیرین و یا pros یا cons رو خوب نمیگن. من به عنوان یک مهندس نرم افزار وظیفه دارم long time side effect این کار اشتباهو بگم. که تصمیم گیرنده درک بهتری داشته باشه. از حرفام با سند و مدرک و مقاله دفاع کنم. صرفا حرف شما به تنهایی ممکنه اعتبار نداشته باشه. همیشه وقتی یک بحثی میکشین وسط یادتون باشه هم pros باید گفته شه هم cons که شنونده احساس نکنه شما دارین احساسی تصمیم میگیرین و منطقی تصمیم گرفته شه.

۴. سعی کنید brain storming کنید. سعی کنید حوادث رو ارتباط بدین با مشکلی که دارین. مثلا بگین فلان باگ و فلان باگ و فلان باگ به وجود اومد چون اینکارا رو نکردیم. پس بهتره بکنیم. هیچوقت یارکشی نکنید. بگید فلانی همیشه conflict منو رد میکنه یا فلان. این بد ترین چیزیه تو یک تیم. یادتون باشه اینپوتتون قرار نیست همیشه قبول شه. ولی باید با ارزش باشه. یک کامنتی خیلی قشنگ نوشتن: ‌قاتل کار تیمی miscommunicationعه! و برعکسش هم صدق میکنه. برای همین brain storming خیلی میتونه مفید باشه.

۵. از دنیای فانتری فاصله بگیرین. واقعبین باشید. مثلا دیدم برنامه نویسا یک فریم ورک یا یک فیچر اصلا به دردشون نمیخورد ولی اضافه کردن چرا؟‌چون خوششون میاد. چون میخوان یادش بگیرن. این بد ترین کاریه که میتونید تو یک محیط حرفه ای کنید. یا مثلا میرن premature optimization انجام میدن و وقتشونو هدر میدن برای جایی که اصلا نیازی نبوده. یا بیش از حد کلین کد میزنن رو پروداکتی که requirement اش روز به روز تغییر میکنه. پس همیشه سعی کنید از دید model business پروداکتتون به محصولتون نگاه کنید تا بهترین کد هارو بنویسید 🙂 خیلی وقتا دلیل conflict همینه که یکی از دو طرف تو دنیای فعلی نیست.

@ManiFoldsPython

بعد توضیح اینا تو یک پاسخ خیلی کوتاه, من چیکار میکنم موقع conflict؟
۱. سعی میکنم اشتباهاتی که بالاتر اشاره کردم نکنم
۲. سعی میکنم به یک نقطه اشتراک برسم بعد از درک طرف مقابلم و ببینم دلیل تصمیمش و مخالفتش چیه؟
۳. سعی میکنم نظر بقیه هم بپرسم و یک brain storming انجام بدم به مشکل.
۴. اگه راهکاری معرفی شه توسط خودم یا یکی از تیم که هم نقاط نظر من و هم conflict دهنده توش رعایت شده باشه انجام میدیم. اگه نه , جمع بندی رو یک جایی ظبط میکنم که بدونیم همچین conflict ای بوده قبلا که از این مشکلات ناشی میگیره و راهکاری براش هنوز پیدا نکردیم که بعدا دوباره فکر کنیم بهش.

در نهایت conflict اینطوری برطرف میشه.
@ManiFoldsPython

این سوال مصاحبه behavioural خیلی از شرکتا هست. خیلیم قشنگ میتونن خیلی پیچیده ترش کنند و به چالش بکشنتون. حتما رو این صورت سوال خیلی فکر کنید. برای career خودتونم خیلی مهمه. جواب من ممکنه درست باشه ممکنه درست نباشه. برای همین کامنت گرفتم اول که ببینم بقیه چیکار میکنن. اگه موافقین/مخالفین خوشحال میشم کامنت کنید و شرکت کنید تو بحث.

@ManiFoldsPython

ساموئل و تیم pydantic زدن تو کاره یک فریم ورک UI که بتونید reusable react component بنویسید با استفاده از pydantic
توصیه میکنم readmeشو بخونید خیلی مطالب خوبی داره

https://github.com/samuelcolvin/FastUI

قبلا تلاشای زیادی بوده ولی همیشه fail میشدن. ببینیم samuel چیکار میکنه :))

@ManiFoldsPython

تلگرام تو نسخه آخر مکش مموری لیک هم داره 🤦‍♂️
وقتی بازش میکنم ۲۰۰ مگ داره مصرف میکنه کم کم زیاد میشه
دو بار رو ۴ گیگ بستمش :))

@ManiFoldsPython

یک تعریف خوب از کتاب clean code in python درباره ریفکتورینگ :)

@TorhamDevCH

نسخه 0.0.2 پکیج cfcrawler منتشر شد 🔥

Change Log:
- Fix compatibility to support python >=3.9

--------
پکیج cfcra‍wler یک پکیج پایتونی هست که async هست و کاملا in-place هست با httpx که به شما اجازه میده سایت هایی که تحت پوشش cloudflare هستن رو درخواست بزنید بهشون و ۲۰۰ بگیرین.

برای حمایت لطفا ستاره بدین یا contribute کنید یا issue بزنید 🙌

🔗 https://github.com/ManiMozaffar/cfcrawler

pip install cfcrawler
from cfcrawler import AsyncClient

async def main():
    client = AsyncClient()
    response = await client.get("https://cloudflare.com")

@ManiFoldsPython

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

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

خوندن سورس کد پروژه ها تو گیتهاب خیلی کمکتون میکنه.
https://github.com/Netflix/dispatch
پروژه توسط netflix نوشته شده. یک incident manager هست که g-suite و jira و اسلک و اکثر سورس هارو مدیریت میکنه با کاستومایز بالا.

پروژه کاملا sync هست متاسفانه. ولی بازم خیلی جا داره برای یادگیری. نکته جالب پروژه خیلی ساده بودنشه.
اگه ببینید متوجه میشین بیشتر فانکشنال کد زدن. نه clean architecture داشتن نه خیلی پیچیده کردن داستانو با ۱۰۰ مدل دیزاین پترن مختلف. من نقض نمیکنم اینارو ها ولی هرچیزی باید به جاش استفاده شه و drawback هاش درنظر گرفته شه. چه OOP چه clean architecture.

یک جاهایی هم OOP کد زدن. مثلا سیستم پرمیشن که طراحی کردن رو واقعا دوست داشتم, خیلی ساده و تمیز.
https://github.com/Netflix/dispatch/blob/ad74b8016c372811b713fe21e275c5e3e4c2a184/src/dispatch/auth/permissions.py#L33

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

@ManiFoldsPython

لینک گروه کانال: دوست داشتین عضو شین. بحث های خوبی میشه یک وقتا خودم خیلی استفاده میکنم 🙌

https://news.1rj.ru/str/PythonFellow

@ManifoldsPython

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

https://pypistats.org/


مثلا sqlalchemy تو روز گذشته ۲ میلیون دانلود داشته در حالی که ‍tortoise orm تو یک ماه گذشته کلا ۱۰۰ هزار دانلود داشته. ولی ستاره هاشو باهم مقایسه کنید میبینید فقط sqlalchemy دو برابره tortoise ستاره خورده پس مشخصا sqlalchemy به مراتب خیلی بیشتر استفاده میشه داخل شرکتا تا tortoise

احتمالا بشه امار فیک هم درست کرد پس خیلی objective نگاه نکنید. چیزایی مثل تست و داک و learning curve و دپندسی هاش هم مد نظرتون باشه.

پ.ن:‌آمار دانلود cfcrawler رو میتونید ببینید تو عکس 😁 تا الان ۲۲۵ نفر نصب کردن.

@ManiFoldsPython

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

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

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

یک پست دوست داشتم بنویسم, راجب review کردن و نگه داری یک PR با بست پرکتیس هایی که باید رعایت شه

اولا study نشون داده که شما هرچقدر بیشتر وقت بذارین رو review کردن یک PR همونقدر پروداکتتون جلوتر میفته. یعنی چی؟ مگه میشه؟‌اره خب , شما هرچی زودتر جلوی باگو بگیری زمان کمتری براش صرف میکنی. قبل کد زدن بهترین موقع برای پیدا کردن باگه!‌(یک requirement خیلی خوشگل و تمیز). در درجه بعدی موقع کد زدن و فکر کردن به کدی که میزنید. در درجه بعدی موقع بررسی PR. در درجه بعدی رو dev و بعد رو staging و در نهایت رو پروداکشن. چرا اینو میگم؟‌چون مثلا اگه یک باگی پیدا کنیم که تو staging باشه ولی تو پروداکشن نباشه یعنی یکی از pr ها مشکل بوده. ولی مشکل که بره رو پروداکشن خیلی سخت تر میشه track اش کرد که دقیقا منشا اش کجا بوده و بیشتر طول میکشه چون پهنا بیشتری داره.

حالا سوال اینجاست چیکار کنیم موقع review؟ اولین کاری که میکنید اینه که requirement رو نگاه میکنید و تو ذهنتون آنالیز میکنید چه چیزایی نیازه. بعد رو کد میگردین دنبال edge case. ممکنه حتی تو requirement هم به edge case و باگ برسین! تا اینجا فقط باگای لاجیکاله. در درجه بعدی سعی میکنید تستا رو بخونید. اگه pr ای تست نداره, فیچری تست نداره بهتره اصلا مرج نشه. تستا رو که خوندین حتما کیس هایی هست که دستی باید تست شه حداقل یک بار. کیس هایی که شاید خیلی خوب نمیشد تست اتوماتیک نوشت براش. میرین و checkout میکنید و یک دور تست دستی هم انجام میدین. احتمال اینکه باگ پیدا کنید خیلی زیاد میشه اینطوری. و درنهایت میپردازین به مباحث دیزاین کد و پرفومنس اگه جایی مثلا نیاز به decoupling داشت یا جایی نیاز. بود یک ‍queryبهینه تر نوشته شه.

با این فرمول اگه برین جلو اکثر مواقع PR به ‍changes requested میخوره مخصوصا برای نیروی جدید. سعی کنید یک PR رو خیلی گنده نکنید چون review اش خیلی سخت تر میشه و احتمال پیدا کردن باگ کمتر.
یک مشکل دیگه که خیلیا انجام میدن اینه که داخل PR میان بیشتر از تایتلش انجام میدن. مثلا طبق git flow مشخصه یک PR چه چیزایی میتونه باشه. یک pr همزمان نباید هم یک issue رو درست کنه هم یک فیچر اضافه کنه. اگه وسط توسعه به اون issue رسیدین و شناساییش کردین باید یک برنچ جدا بسازین, اون ایشو رو اونجا درست کنید با تست فیل و cherry pick کنیدش رو برنچ فیچری که داشتین کار میکردین که جداگانه review شه و سریعتر مرج شه.

@ManiFoldsPython

این کالچر خیلی جا داره تو ایران قوی شه و واقعا کیفیت یک پروداکت رو به مراتب خیلی بیشتر میکنه... طبق چیزی که از بچه ها میشنوم اکثرا تو شرکت ایرانی میبینن تست پاس شده approve میکنن. خب چرا زحمت میدین به خودتون؟‌یک گیت هاب اکشن بنویسید هر pr ای تستاش انجام شد approve شه دیگه 😁 یا اکثرا موقع بررسی pr فکر میکنن فقط باید ایراد به دیزاین و پرفومنس بگیرن. در صورتی که خوده کد کلا کار نمیکنه چه برسه به اینکه بخواد خوشگل باشه یا سریع.
@ManiFoldsPython

خیلی ویدیو باحالیه
این ویدیو به شما نشون میده که تو دنیای امنیت:
۱. کلمه boundary چیه؟
۲. کلمه آسیب پذیری چیه
۳. کلمه ضعف امنیتی چیه

https://youtu.be/LxUAnZY_08o?si=iD2nvFhyJwmEJ6Do

منتهی یک نکته راجب این ویدیو:‌ درواقع ذنجیره ای از ضعف امنیتی میتونن باعث یک آسیب پذیری بشن
امنیت هم یک چیزه نسبیه. یعنی نمیشه گفت فلان کار حتما آسیب پذیریه. بستگی داره boundary تعریف شده برای سیستم چی باشه؟
این ویدیو رو توصیه میکنم حتما ببینید تا دیدتون عوض شه

@ManiFoldsPython

یک میم خیلی جالب راجب همین موضوع :))

توصیه میکنم حتما ویدیو رو ببینید
@ManiFoldsPython