اپدیت اخر فست شما حالا میتونید تو سطح APIتون چندین مثال داشته باشین برای schema 🙌🙌
@ManiFoldsPython

مثال ACL که نوشتم یادتون بود؟ تو اپ دانش آموز

که تو هر روتر مجبور میشدم بیام یک enum بهش بدم که این روتر چیه که بتونه کانفیگو بخونه از ACL

حالا داشتم یک کاری میکردم که کدی که داره چک میکنه پرمیشن روتر رو کاملا بره تو depends که تو همه روتر ها duplicate نشه. تقریبا تا ۹۰درصد مسیرو رفتم ولی خیلی بد شد چون باید APIRouter خود فست کاستومایز میشد.

حالا اگه built in تو خود لایبری میشد برای هر روتر یک enum گذاشت که دیگه نیاز نباشه با path اون روتر شناساییش کنیم خیلی عالی میشد (یک چیز static و با خوانایی بالا). نظرتون چیه؟

اینجا پیشنهادشو گذاشتم اگه موافق بودین حتما upvote کنید. اینطوری کل کد میرفت تو Depends و DI میشد کلا و خیلی تمیز و خوشگل تر میشد کد👌

https://github.com/tiangolo/fastapi/discussions/10156

@ManiFoldsPython

دوستان falsehood یعنی خرافه
یعنی این متنی که مینویسم اینجا از مورد اول تا آخر غلطه.
اینو برعکس کنید درست میشه تازه.

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

مثلا تو این پست من کلی چیز یاد گرفتم:
https://news.1rj.ru/str/manifoldspython/318

مثلا میدونستید ما ساعت ۲۳:۵۹:۶۰ داریم؟

میدونستید که داشتن دو تا UTC Timestampts دلیل نمیشه شما بتونید فاصله ثانیه ایشون رو حساب کنید؟‌اگه یکیشون تو اینده باشه؟‌:)))).

میدونستید کم ترین فاصله بین دو نقطه یک خط مستقیم بینشون نیست؟

آدم اینا رو میخونه کم کم به اطرافیانش شک میکنه 🤣

@ManiFoldsPython

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

https://www.youtube.com/live/UjPYhD2PUVc?feature=share
@ManiFoldsPython

یکی از خفن ترین typing هایی که تو پایتون هست و تو داک pydantic هم حتی بهش اشاره شده لایبری annotated_types هست

خیلی خوبه حتما استفاده کنید!
https://github.com/annotated-types/annotated-types

@ManiFoldsPython

توضیح annotated type از سروش که خیلی کامل بود
و داستانش کلا...

@ManiFoldsPython

من خودم تو مارکت ایران خیلی کار نکردم ولی یکی از برداشت من بعد از هاست شدن یا مشاهده مصاحبات tech immigrant اینه که تو ایران اصلا مهم نیست نرم افزار چقدر تست شه و صرفا سرعت ریلیز مهمه. یعنی اول و آخر تیم product تصمیم میگیرن و تیم develop رو پوش میکنند (البته نه تو همه شرکت ها ولی با اکثر دوستان که حرف میزنم ظاهرا همینطوره)

در حالی که تو اروپا کاملا برعکسه. من دیدم دولوپر ها تو ایران حتی تست هم نمینویسن!
من خودمو مثال میزنم, این هفته ۳۰ ساعت باید کار کنم. از این ۳۰ ساعتی که کار میکنم طبق board حدودا ۲۲ ساعت باید تست بنویسم. ۴-۵ ساعت باید code review کنم, ولی اشتباه نکنید, کد ریویو test هایی که قراره اضافه شن :))
و ۲-۳ ساعت آخر هم باید نوشن اضافه کنم و داکیومنت تست سناریو ها و تست کیس هاو چیزای دیگه رو تکمیل کنم.

این هفته یک خط کد هم فیچر بک اند نمیزنم! با وجود اینکه backend developer هستم.

و دقیقا تو لایو مهندس هم به همین موضوع اشاره کرد که بیشتر تایم رو ما داریم تست مینویسیم تو شرکت و همه چیز کند پیش میره و مشکلی نداره به جاش پروداکتی که میاد بیرون ریلیز میشه خیلی stable هست و ستون بندی خیلی مناسبی داره.

@ManiFoldsPython

اوایل که مصاحبه میرفتم همون اولین مصاحبه رد میشدم,
اما الان تقریبا هروقت مصاحبه میگیرم میرسم به coding challenge یا technical interview
تکنیک هایی که این مدت به کار بردم و جواب داده رو خواستم تو این پست بنویسم تا استفاده کنید:


اولین چیزی که مطرح میشه اینه که شما خودتونو معرفی کنید, تو این مرحله یک summary خلاصه از خودتون بگین و فعلا وارد جزییات نشین.

مهم ترین موضوع اینه که شما به اون شرکت علاقه نشون بدید. این موضوع به قدری مهمه که حتی اگه ممکنه کاندید بهتر از شما باشه ولی شما رو انتخاب کنند چون باعث میشه که فکر کنند شما متعهد تر هستین به اون شرکت تا اون فرد. این علاقه نشون دادن با سوال تخصصی تو اون فیلد میشه نشون داد. بهترین کار هم اینه که سایت شرکت رو دربیارین, اطلاعاتش رو بخونید و بعدش به chatgpt اون اطلاعات رو بدین و بهش بگین که چند تا سوال براتون طراحی کنه که هم یکم چالشی باشه و هم نشون بده که کاملا interested بودین.

اما کی باید این سوالات رو بپرسین؟ معمولا interviewer از شما میخواد که اول به حرفاش گوش بدین و معمولا یک introduction ای از شرکت خودشون و چالش هاش به شما میگه. بعد از شما میپرسه که آیا سوالی دارین یا نه, و بدترین جواب اینه که بگین نه ندارم. همینجاست که سوالاتی که حاضر کرده بودین, باید بپرسین و سعی کنید هم چند سوال راجب توضیحاتی که خودش داده اول بپرسین, حتی اگه کامل فهمیده بودین!


طرفی که باهاش مصاحبه میکنید رو بسنجید و سعی کنید که درجه صحبتتون بر اساس سطح technical اون آدم منطبق کنید. مثلا تو یک مصاحبه خود HR سابقه کد زنی داشت و من تونستم خیلی فنی تر حرف بزنم که تجربه خیلی خوبی برای جفتمون بود. اما اگه همینکارو با HR کنم که old fashion تره, قطعا یک red flag خواهد بود. سطح فنی اش رو از توضیحاتی که راجب شرکتشون میده میتونید ارزیابی کنید.

حالا نیمی از interview گذشته و فقط راجب شرکت حرف زده شده, احتمالا interview از شما بخواد که بک گراند بیشتری راجب خودتون بدین. حالا شما باید به نحوی مهارتتون رو بفروشید, مثلا به هر نحوی شده سعی کنید پروداکت هایی که تا امروز روش کار کردین به پروداکت این شرکت لینک کنید. حتی اگه دروغ بگین یا بزرگ نمایی کنید ایرادی نداره, فقط دروغ فنی نگین یا بزرگ نمایی از خودتون نکنید. مثلا ممکنه تو یک business domain ای اصلا کار نکرده باشین, مثل B2B. ولی اگه شب قبل حسابی راجبش بخونید میتونید ادعا کنید که اره فلان جای پروداکتمون B2B بود و من کمی درگیرش شدم. سعی کنید اگه تو این موارد دروغ میگین, خیلی خوب و متواضعانه دروغ بگین!

تو قسمت آخر هم خیلی خلاصه از یک پروژه خوبی که کار کردین و پیچیدگی بالایی داره یا impressive هست میتونید صحبت کنید, سعی کنید خیلی کشش ندین چون این پارت برای اینه که شما یک تاثیری بذارین رو فرد مصاحبه کننده, نه اینکه خستش کنید.


سعی کنید متواضع باشین, اینکه بگین من همه چی رو بلدم خوب نیست. حتی به یک نقطه ضعفتون هم اشاره کنید بد نیست و بگین که مثلا روش کار میکنید, و حتما نقطه ضعفی که انتخاب میکنید برای اون شرکت critical نباشه و فقط این وایب رو به اون مصاحبه کننده بده که این ادم تمام تلاششو میکنه تا خودشو بالاتر میکشه از اینی که هست.


@ManiFoldsPython

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

یک پوزیشن پایتون هم هست اگه دوست داشتین میتونید اپلای کنید
https://boards.eu.greenhouse.io/kambi/jobs/4202150101?source=LinkedIn

@ManiFoldsPython

راجب اصول تست نویسی, یک مقاله پیدا کردم, میخوندمش مفید و کلی بود
به عنوان یک software engineer حداقل باید با مفاهیم اشنا باشین که وقتی با کلمه های زیر خوردین فکر نکنید چیز خیلی عجیب و فضایی هستند. نمیگم بلدشون باشید ولی باید بدونید چی هستند. دونستن این موارد کمک میکنه بهتون که به عنوان یک SE بهتر کد بنویسید و بهتر تست بنویسید.

- Testing Strategy
- Test policy
- Test scenario & Test case
- Software requirements, and requirements review
- Types of automated testing (A/B, smoke, unit, integration, e2e, exploratory, stress, load, perfomance, regression, cross-device, crowss-browser, acceptance, black box, Operational acceptance, conctract acceptance)
- Types of manual testing (exploratory testing, ad hoc testing)
- Software quality indicators
- Test Metrics


لینک مقاله:
https://www.altexsoft.com/blog/engineering/software-testing-qa-best-practices/


@ManiFoldsPython

یک تمرین میذارم که انجام بدیم, بعدش ویدیو میگیرم و خودم دقیقا همینکارو میکنم, از اون تمرین هاست که ظاهرش به شدت راحته ولی باطن به شدت سخت.

وقتی شما تو یک شرکت خوب کار کنید اولین چیزی که باهاش مواجه میشین strict code review هست.
یکی کدتون رو به حدی review میکنه که مجبور میشین ۴-۵ بار تغییرش بدید تا کد مرج شه.
خیلیم ربطی به level برنامه نویسی نداره هر انسانی موقع نوشتن کد قطعا یک سری خطایی میکنه که هدف code review کم کردن اون احتمال اون خطاست.

پی نوشت:‌عکس نشون میده چرا code review و pair programming میتونه مفید باشه
@ManiFoldsPython

اولین کد, مدل دیتابیس
ایرادات این کد رو پیدا کنید و کامنت کنید 👀

با sqlalchemy نوشته شده...
این مدل قراره فایل های آپلود شده رو تو دیتابیس مسیرشو ذخیره کنه و بگه از چه source ای اومدن (مثلا سورس فایل آپلود شده چی بوده) و کی آپلودش کرده

@ManiFoldsPython

دومین تیکه کد
داره یک سری فایل میگیره
و ذخیرش میکنه تو سیستم
کانتنت تایپشونو چک میکنه

و ارور raise میکنه اگه مشکلی داشت

مشکل این کد؟ (حداقل ۱۰-۱۵ تا مشکل داره این تیکه کد)

@ManiFoldsPython

تیکه اخر کد
قسمت روتر

@ManiFoldsPython

تو این ویدیو پرداختم به نحوه code review و clean code
یک کد FastAPI که خوب نبود و نیاز به ریفکتور اساسی داشت رو باهم ریفکتور کردیم و توضیح دادم دقیقا چرا ریفکتور کردم و چرا نسخه ریفکتور شده بهتره

خود کد رو از این ریپو میتونید ببینید
https://github.com/ManiMozaffar/dirty-code

نکته:‌ آخر ویدیو یادم رفت که database model رو داخل دیتابیس add کنم. داخل کد کمی تغییر دادم که این موضوع رعایت شده.


™️ @DjangoIR
〰〰〰〰〰〰
© @DjangoEx |
© @ManiFoldsPython

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

بنظرتون, چطور میتونم محتوا تولید کنم تو این زمینه؟ مخصوصا تست نویسی🤔اگه ایده ای دارید خوشحال میشم کامنت کنید

پ.ن: سری ویدیو ریفکتور و code review رو ادامه میدم سعی میکنم ویدیو های بعدی کوتاه تر شه که بتونیم نحوه نوشتن کد maintainable رو باهم تمرین کنیم.

@ManiFoldsPython

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

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

مثال میگم, کسی که کتاب two scopes django رو خونده باشه اونجا نویسنده میگه که تو جنگو تمام assert ها رد میشن موقعی که دیباگ رو false میذارین. دلیلش چیه؟ دلیلش اینه که شما وقتی پایتون رو آپتیمایز ران میکنید (و خود پایتونم از حالت دیباگ خارج میشه که با داندر دیباگ میتونید ببینید) یکی از کار هایی که میکنه تمام assertion هارو ایگنور میکنه. پس شما وقتی two scopes رو دارید میخونید باید بعد اون جمله ای که نوشته یک چرا بذارید و گوگلش کنید. چرا اینکارو میکردن؟‌ قطعا یک دلیلی دارن دیگه... جنگو core دولوپر ها که الکی کدی وارد جنگو نمیکنن... عمق اطلاعاتتون هم در همین راستا زیاد میشه.

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

مثال دیگه وقتی شما مینویسی router.post باید بدونید داره چه اتفاقی میفته. اینکه میاین validation حجم باینری فایل input رو توی خود روتر مینویسید یعنی عمق سواد HTTP نداشتین.
مثال دیگه اینکه داریم کد رو decouple میکنیم که reusable شه باید بدونید چرا داریم اینکارو میکنیم. برنامه نویسی جغرافی نیست. من دیدم بعضیا میگن چون فلان کتاب یا فلان شخص گفته, دنبال راه حل اونا نباشید تو مرحله اول شما باید صورت سوال رو درک کنید تا بعد بتونید راه حل اونا رو درک کنید.

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

@ManiFoldsPython

وقتی میگفتم این هفته فقط باید تست بنویسم و ‍code review تست بکنم شوخی نمیکردم :))
کانتربیوت امروز گیتهابمه
پی نوشت: اون ۴ تا review ای که کردم هم unit test بوده رو یک ریپو دیگه

@ManiFoldsPython

بعضیا پرسیدن من چطوری مثلا تست نویسی رو یاد گرفتم, مثلا چه کتاب خاصی خوندم یا چه دوره ای دیدم..

بنظره من کلا اشتباهه که شما ۱ کتاب بخونی و بعد بگی اوکی من یاد گرفتم. چون اون کتابو یک انسان نوشته, و ذهنیت اون انسان پشت اون کتاب بوده. برای همین من شخصا ترجیح میدم تو همچین چیزایی برای اینکه ذهنم bias نشه به جاش ۳۰-۴۰ تا article بخونم که کار همون یک کتاب رو میکنه برای من ولی از دید ۳۰-۴۰ نفره مختلف..

امروز ۲ تا آرتیکل خوندم براتون میذارم اینجا راجب تست نویسیه

اولیش راجب اینه که always assert the failing test first توی یونیت تستاتون. خیلی وقتا assertion ای که میذارین شما برای حل یک چیزی (مثلا میگین فلان چیز خرابه)‌اشتباهه. در صورتی که assertion شما اشتباهه و دلیل باگ اون چیزی که شما فکر میکردی نیست و طبق همین assertion جلو میرین و کد رو تغییر میدین. تغییراتی که دادین کلا وقتتون رو هدر دادین و حالا احتمالا باگ جدید هم درست کردید. پس به جای سرو کله زدن با یک باگ باید با ۲ باگ سرو کله بزنید. برای همین تو اولین قدم سعی کنید تستی بنویسید که اون خطا رو reproduce میکنه تو مینیمال ترین حالت ممکن. (دقیقا ‍unit ای که fail میشه باید براش تست بنویسید). اینطوری خیلیی راحت دیباگش میکنید و یک چهارم وقتتون گرفته میشه.
اینجا خیلی کامل توضیح داده
https://canro91.github.io/2021/02/05/FailingTest/

نکته دوم راجب confidence بود تو تست نویسی. تستی که مینویسیم واقعا چقدر اطمینان میده به ما که محصولمون کار میکنه؟ چقدر ارزش داره؟ این مقاله راجب همینه
https://meeshkan.com/blog/defining-confidence-in-software-testing/

@ManiFoldsPython