Python BackendHub – Telegram
Python BackendHub
7.51K subscribers
314 photos
46 videos
11 files
432 links
Learning python & Backend Engineering, with Mani!

Youtube: https://www.youtube.com/@GitOverHere
Github: https://github.com/ManiMozaffar
Linkedin: https://www.linkedin.com/in/manimozaffar

تبلیغات نداریم

Admin: @Mani_nikou
Download Telegram
سوال دوم:
برای اینکه پروژه پروداکشن بزنیم چقدر تکنولوژی باید بلد باشیم؟‌چقدر دیپ باشیم خوبه؟

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

ولی اگه صرفا جنبه تمرینی داره, بله به نظره من پروژه های تمرینیتون رو باید در حد پروداکشن کوالیتی بنویسید که یکم خلاقیت پشتش باشه. اینکه یک نفر ویدیو بذاره پروژه بزنه شمام همونو کپی پیست کنید هیچوقت یاد نمیگیرین. پس سعی کنید برای خودتون بیزنسی تعریف کنید(مثل صرافی). و واقعا بسازیدش. حالا نمیخواد خیلی پرفکت کار کنه ولی همینکه با چالش هاش مواجه شید متوجه میشید. یک چیزی باشه که خودتون هم ازش استفاده کنید خیلی به نفعتونه. ولی طبیعتا تا زمانی که رو پروداکشن واقعی کار نکردین یک سری تجارب رو بدست نمیارید. اشکال نداره. بعدا که استخدام شدید به دست میارین. فرار نمیکنن اون تجارب :)). خیلی مهمه که شما به سمت اون تجربه ها برید چون اون تجربه ها هیچوقت سمتتون نمیان.


در خصوص عمق تکنولوژی که یاد میگیرین بنظره من باید سیستم دیزاین و کلین کد رو بلد باشین تا یک پروژه تمرینی و پروداکشن کوالیتی بنویسید.

نکته بسیار مهم:‌دوستان شرکت های بزرگ و خارجی دیگه دنبال برنامه نویس جنگو نیستند دنبال مهندس نرم افزار هستند. برنامه نویس جنگو کسیه که مثلا جنگو رو خیلی دیپ شده. ولی مهندس نرم افزار کسیه که کانسپت هارو خیلی خوب بلده و میدونه چی رو کجا باید استفاده کنه. کلی کتاب و ریسورس هست برای سیستم دیزاین. و کد با کیفیت نوشتن (از کتابای martin fowler و آنکل باب بگیرید تا همین کورس های یوتیوب آریان)

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

من همین ۲-۳ سال اخیر اینقدری که عمیق شدم تو کراولینگ و کلا دیتکت ربات و مشابه سازی رفتار مرورگر و اینکه تو مرورگر چه اتفاقاتی دقیقا داره میفته که میتونم براتون ۲۰ صفحه مقاله بنویسم شما از وقتی که مثلا میرین تو یک سایتی که زیر دیکیتشن cloudflare هست تو حالت under attack اش چه اتفاقاتی داره میفته و دقیقا چطوری دیتکتتون میکنه. (یک چیزی که شاید بنظرتون یک get request خیلی ساده باشه). و هنوزم میگم هیچی نمیدونم راجب این پروسه یعنی عمق این پروسه رو میشه تو ۲۰۰ صفحه نوشت! پس شما تو هر کانسپتی که فکر کنید برید دنبال عمق یک چیزی هیچوقت به تهش نمیرسید. فقط باید تو چیزایی عمیق شید که لازم دارید.

@ManiFoldPython
👍163
یک نکته که جا موند, شرکتی بهتره که موقع PR خیلی با حساسیت بررسی میکنن کداتون رو. همینطوری الکی مرج نمیکنن بره پی کارش. صرفا هدفشون این نیست تند تند فیچر بزنن و سعی میکنن پروداکت stable ای داشته باشن.
پیدا کردن همچین شرکت هایی خیلی سخته.
شرکت هایی که اجازه میدن یک کارو خیلی عالی انجام بدید تا اینکه چند تا کارو انجام بدید خیلی خوب هستند و به شدت باعث پیشرفتتون میشن

و اینکه اصلا غر نزنید از تسک جدید. اگه تسک جدید تو شرکت هست سعی کنید داوطلب شید. هر تسک R&D یعنی شرکت داره به شما پول میده که داکیومنت بخونید و یاد بگیرین!‌ چی میخواین بهتر از این؟‌ حتی اگه نامرتبط هم باشه حتما برین سمتش. مثال میگم خودم داوطلب شدم تمام تسک های QA رو انجام بدم. میتونستم داوطلب نشم و گردن یکی دیگه بیفته. (مگه اینکه خیلی تسکه دیگه تو دیوار باشه و ربطی به software engineering کلا نداشته باشه :))‌ )


پ.ن:‌از روز اولی که تو شرکت فعلیم کار کردن نپرسیدن ازم که مانی چرا فلان PR رو تمو نکردی هنوز یا فلان فیچر چی شد؟

@ManiFoldPython
👍12
ریپو رزومه نویسی من.
برای اینکه شانس مصاحبه گرفتنتون بالا بره باید رزومه خوب داشته باشین. رزومه خوب داشتن فقط به این معنی نیست که سوابق کاریتون خوب باشه. میتونید با سوابق کاری کم هم رزومه اتون رو طوری بنویسید که شانس مصاحبه گرفتنتون از اون کسی که چند برابر شما تجربه داره و رزومش ضعیفه خیلی بیشتر شه.


https://github.com/ManiMozaffar/awesome-resumes

این ریپو اینقدر نکته داره که من تقریبا به هر ۱۰۰ رزومه ای که نگاه میکنم ۹۹تاش مشکلاتی دارن که دقیقا تو این ریپو گفته شده.

پی نوشت:‌این ریپو حاصل چند ماه تحقیق و نگاه کردن ویدیو های tech immigrants بوده.

@ManiFoldsPython
23👍2
اگه از پکیج certifi استفاده میکنید حتما آپدیتش کنید به آخرین نسخه
دلیلش:
https://github.com/advisories/GHSA-xqr8-7jwr-rhp7

@ManiFoldsPython
👍5
دیباگینگ فقط اونجاش که شک میکنی مشکل از لایبریه سوپر mature هست یا کده تو 😂

@ManiFoldPython
😁20🤣5💩4
یکی از دوستان ریپوشو شیر کرده بود با من یک نکته ای دیدم که گفتم حتما راجبش پست بذارم

Custom exception

اولا برای خطا ها لاجیک هیچوقت از built in exception های پایتون استفاده نکنید. شما هیچ لایبری رو نمیبیند که همچین کاری کرده باشه. فقط زمانی نیازه که واقعا اون ارور دقیقا همون چیزیه که built in python هست و جایی نیاز ندارید لاجیک یا هندلری براش بذارید

خیلیی استفاده کنید از این کانسپت! سعی کنید تایپ هینتتون رو با اکسپشن درست کنید!‌همیشه اکسپشن بیس بسازید. من هر ریپویی میسازم اولین کاری که میکنم اینه که یک exception.py میزنم و بعد شروع میکنم به کد نویسی.

قدرت اکسپشن خیلی زیاده. خیلی flexible هست. شما میتونید رو اکسپشن لاجیک بنویسید. و سرعت ران تایم برنامتون رو به شدت ببرین بالا.
مثال میگم, یک رباتی نوشتین که داره اوردر ثبت میکنه تو یک سایتی

make_order(order_info: OrderRawData) -> Order

اگه مشکل داشت NONE برنگردونید!!

و توش اگه نا موفق بودید raise میکنید اکسپشن های مختلف رو. اینطوری یک برنامه یک دست دارید. مثلا اگه مشکل احراز هویت بود raise ExpiredToken. حالا میتونید تو یک سطح بالاتر کدتون, اکسپشن های مختلف رو هندلر براش بنویسید. catch کنید و پاسش بدید به اون هندلر. اینطوری میتونید یک لاجیک خیلیی تمیز بنویسید. اگه هندل نشده بود لاگ بندازین که براش بعدا هندلر بنویسید


تایپ ریترن تابع شما حتما باید یک تایپ باشه. none وقتی برمیگرده یعنی حاصل اون flow تابع شما هیچ دیتایی نبود. پس تو این مثال make_order اصلا نباید None برگرده!

حالا بگین کدوم خوانا تره؟

make_order(order_info: list[OrderRawData] | Order) -> Order | list[Order] | None

تابع شما باید به قدری خوب ‍type hint داشته باشه و تایپاش مشخص باشه و به قدری خوب اسم گذاری شده باشه که کی فرد با خواندن اسم تابع شما و تایپ هینت و I/O متوجه شه دقیقا تابع چیکار میکنه بدون اینکه بخواد کد رو ببینه.

@ManiFoldsPython
👍3914🔥13🙏2
Python BackendHub
یکی از دوستان ریپوشو شیر کرده بود با من یک نکته ای دیدم که گفتم حتما راجبش پست بذارم Custom exception اولا برای خطا ها لاجیک هیچوقت از built in exception های پایتون استفاده نکنید. شما هیچ لایبری رو نمیبیند که همچین کاری کرده باشه. فقط زمانی نیازه که واقعا…
وقتی دارین تو function شما چند تا اینپوت میگیرین
اینپوت هاتون به هیچ وجه نباید تو اون فانکشن کلین کنید. نباید تایپشون رو همون اول تغییر بدید. فانکنشو برای یوز کیستون فقط ننویسید سعی کنید کلی بهش نگاه کنید. فانکشن رو جوری بنویسید که همه جای کد بتونید ازش استفاده کنید

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

یک مثال مثال بد:

class Bank():
...

def create_bank_account(account_id: str | None, balance: int) -> Bank:
if isintance(account_id, str):
account_id = UUID(account_id)
if not account_id:
account_id = generate_random_uuid()

if not balance > 0:
raise SomeError("Balance should have been higher than 0")
return Bank(id=account_id, balance=balance)


خب من هر استرینگی بدم این میخواد uuid کنه. پس چرا uuid نگرفت؟ چرا نان میگیره بعد اگه نان بود خودش uuid میسازه؟ بهتر نبود این فانکشن دیکاپل شه و تو سطح کلاس این دیفالت initiate کردن انجام شه؟

ریفکتور شدش:


class Bank():
...

class PositiveInt:
...

def create_bank_account(account_id: UUID, balance: PositiveInt) -> Bank:
return Bank(id=account_id, balance=balance)


پس تو کدتون این موارد رو همیشه رعایت کنید:
Specific Typing
Separation of Concerns
Reusability
Explicit Contracts
Testability

@ManiFoldsPython
👍19
Python BackendHub
Live coding assignment: School Student App لینک گوگل میت: https://meet.google.com/mum-umcx-qwt یک شنبه ساعت ۲۰ تا ۲۱:۳۰ ۱۵ دقیقه اول فقط تسک رو میخونم. خیلی مهمه این موضوع. سعی کنید miss نکنید ۱۵ دقیقه اولو. مفاهیمی که تو ۱۵ دقیقه اول توضیح داده میشه:…
فردا لایو کد داریم و هنوز کسی کد نفرستاده 👀
صرفا چون کدی کار میکنه دلیل بر خوب بودنش نیست.

اگه کسی تموم کرده حتما بفرسته برای من لینک گیتهابشو. وقتی ۲ سمپل داشته باشیم هم راه کار متفاوت و پاسخ های متفاوت به اون سوال در میاد

هم کلی ایراد از کد من و کد اون شخص درمیاد.
هم اینکه یکم رو کالچر کد review کار میکنیم و مثال میزنیم که چطور code review باید انجام شه. دیروز که با دوستان صحبت میکردم ظاهرا اکثر شرکت ایرانی همچین کالچری ندارن رو code review و PR ها اکثر مرج میشن بدون تغییر زیادی...
@ManiFoldsPython
5👌2
دوستانی که Event driven کار میکنن با کافکا و rabbitmq و اینا سرو کله میزنن

به این دو پروژه یک سر بزنید

Propan
https://github.com/lancetnik/propan
https://lancetnik.github.io/Propan/

FastKafka
https://github.com/airtai/fastkafka
https://fastkafka.airt.ai/

واقعا لیاقت گرفتن ستاره رو دارن اگه میتونید حتما ازشون حمایت کنید. خیلی ایدشون قشنگه و میتونه تحول بزرگی ایجاد کنه. جفتشون هم به شدت دارن maintain میشن 🙌🙌
@ManiFoldsPython
7👍3
Live coding assignment: School Student App

لینک گوگل میت:
https://meet.google.com/mum-umcx-qwt


دو ساعت دیگه شروع میشه...
یکی از دوستانم فرستاد پروژش رو. بنابراین من سعی میکنم schema دیتابیس و presentation رو از قبل حاضر کنم
که نهایتا یک ساعته جمع کنم و وقتتون رو خیلی نگیرم. بعد بپردازم به Question & Answer و البته ریویو کد دوست عزیزمون

@ManiFoldsPython
👍4436🔥12🐳12👏3
پنج دقیقه دیگه شروع میشه.
لینک بازه از الان.
10👍1🔥1
ببخشید دوستان یکم طول کشید...
میخواستم کامل توضیح بدم که جای سوال نمونه واقعا.
کلش رو record کردم. آپلود میکنم. چند پارت مختلف تقسیم میکنم بعد آپلود میکنم.

نهایتا ACL ما اینطوری پیاده شد. یک dictionary که میتونست ورودی برنامه باشه (از دیتابیس) و کاملا قابل flexible

شاید وقت گذاشتم همین رو پکیج پایتونی کردم برای فست.. ولی یکم سخته چون خیلی felixable هست ACL و نمیشه به این راحتی پکیجش کرد

@ManiFoldsPython
👍196🔥1
نظرتون رو بگید حتما

دوست دارم فیدبک بدید که چطور بود؟‌متوجه شدین؟‌ تا جایی که بودید؟
چه ایراداتی از من میگیرین؟‌زیاد توضیح میدادم؟‌ کلا دوست دارم فیدبکتون رو بشنوم.


@ManiFoldsPython
👍126
Media is too big
VIEW IN TELEGRAM
نحوه خواندن یک کدینگ چلنج
@ManiFoldsPython
13👍3
Media is too big
VIEW IN TELEGRAM
توضیح کوتاهی راجب تست نویسی و اصول و انواع تست در SDLC

@ManiFoldsPython
15
Media is too big
VIEW IN TELEGRAM
دیزاین دیتابیس کدینگ چلنج و نکات مربوطه دیزاین
@ManiFoldsPython
12🔥3
Media is too big
VIEW IN TELEGRAM
دیزاین کلی API اپ دانش آموز
@ManiFoldsPython
9👏2👍1
Media is too big
VIEW IN TELEGRAM
JWT Design
چرا از فانکشن استفاده کردیم؟
و چند بست پرکتیس موقع فانکشن نویسی
@ManiFoldsPython
11