ابزار WSL ویندوز چیه؟
ابزاری که مایکروسافت طراحی کرده تا بتونید یک محیط لینوکسی رو تو ویندوز اجرا کنید یعنی دیگه نیاز نیست از ماشین مجازی استفاده کنید
این WSL به منابع کمتری نسبت به یک ماشین مجازی کامل نیاز داره درحالی که به کاربر ها اجازه میده فایل های خودشونو تو هردو محیط ویندوز و لینوکس استفاده کنن.
در سال 2019 نسخه دوم (WSL 2 ) معرفی شده که توی ماشین مجازی مدیریت شده اجرا میشه و یه کرنل کامل لینوکسی داره و همه برنامه های لینوکسی رو اجرا میکنه.
من باهاش Debian رو نصب کردم. کل فرایندش حدودا نیم ساعت شد.
همونطوری هم که توی تصویر مشخصه، اضافه میشه به منو start فعلا با مشکلات احتمالی ش آشنا نیستم.
اگه موردی دیدم، توی کامنت های همین پست میزارم.
با تشکر از کانال CHET CODE
ابزاری که مایکروسافت طراحی کرده تا بتونید یک محیط لینوکسی رو تو ویندوز اجرا کنید یعنی دیگه نیاز نیست از ماشین مجازی استفاده کنید
این WSL به منابع کمتری نسبت به یک ماشین مجازی کامل نیاز داره درحالی که به کاربر ها اجازه میده فایل های خودشونو تو هردو محیط ویندوز و لینوکس استفاده کنن.
در سال 2019 نسخه دوم (WSL 2 ) معرفی شده که توی ماشین مجازی مدیریت شده اجرا میشه و یه کرنل کامل لینوکسی داره و همه برنامه های لینوکسی رو اجرا میکنه.
من باهاش Debian رو نصب کردم. کل فرایندش حدودا نیم ساعت شد.
همونطوری هم که توی تصویر مشخصه، اضافه میشه به منو start فعلا با مشکلات احتمالی ش آشنا نیستم.
اگه موردی دیدم، توی کامنت های همین پست میزارم.
با تشکر از کانال CHET CODE
👍9❤3✍1
Forwarded from TheAliBigdeli Channel
مدیریت خطا و پیامها
تو هر پروژهای خطا اجتنابناپذیره، مهم اینه چطور باهاش برخورد کنیم. اگه پیامها درست مدیریت نشن، هم کاربر گیج میشه، هم فرانت سختتر میتونه هندل کنه.
چند تا نکته به عنوان best practice:
- برای خطاها یه ساختار مشخص داشته باش تا فرانت بتونه راحت تشخیص بده با چه شرایطی طرفه.
- پیام برای کاربر باید ساده و قابل فهم باشه، نه پر از اصطلاحات فنی.
- جزئیات فنی و لاگها رو نگه دار برای بکاند و تیم فنی، نه برای کاربر.
- همیشه از پیامهای عمومی برای خطاهای پیشبینینشده استفاده کن (مثل "مشکلی پیش اومده، دوباره امتحان کن").
- خطاها رو دستهبندی کن (مثلاً خطای کاربر، خطای سرور، خطای دسترسی) تا بتونی راحتتر مدیریت کنی.
از مهمترین شرایطی که باید یک توسعه دهنده بک اند در API لحاظ کنه Custom Exception Handler هستش تا بتونه خطا ها رو با یک فرمت مناسب و یک دست پاسخ بده و این موضوع بر اساس کمپانی های مختلف متفاوت هستش ولی می تونین الگوی مناسبی رو از درونشون پیدا کنین.
مثلا داشتن کلید error در پیام و همچنین در ادامه status کد خطای اتفاق افتاده و همچنین جدا سازی detail و message که در یکی خطای توسعه و دیگری پیام قابل نمایش به کاربر قرار میگیره. در بعضی شرایط ممکنه حتی timestamp و اطلاعات بیشتری هم درج بشه مثلا code یا type که ممکنه شماره خطای خاص و یا کلید واژه مربوطه برای ردگیری خطای سریعتر باشه.
دیده میشه گاهی وقتا آدرس و یا حتی ورودی ها رو هم در بعضی سرویس ها نشون میدن که به نظرم جاش توی ریسپانس نیست و باید توی لاگ ها باشه و با این حال بعضی سرویس ها ارائه میدن.
نمونه Response مناسب برای خطا ها
رفرنس ها:
- https://zuplo.com/learning-center/best-practices-for-api-error-handling
- https://api7.ai/learning-center/api-101/error-handling-apis
- https://nordicapis.com/5-real-world-examples-of-great-api-error-messages/
- https://www.baeldung.com/rest-api-error-handling-best-practices
📢 @thealibigdeli_channel
#api_design
#api
تو هر پروژهای خطا اجتنابناپذیره، مهم اینه چطور باهاش برخورد کنیم. اگه پیامها درست مدیریت نشن، هم کاربر گیج میشه، هم فرانت سختتر میتونه هندل کنه.
چند تا نکته به عنوان best practice:
- برای خطاها یه ساختار مشخص داشته باش تا فرانت بتونه راحت تشخیص بده با چه شرایطی طرفه.
- پیام برای کاربر باید ساده و قابل فهم باشه، نه پر از اصطلاحات فنی.
- جزئیات فنی و لاگها رو نگه دار برای بکاند و تیم فنی، نه برای کاربر.
- همیشه از پیامهای عمومی برای خطاهای پیشبینینشده استفاده کن (مثل "مشکلی پیش اومده، دوباره امتحان کن").
- خطاها رو دستهبندی کن (مثلاً خطای کاربر، خطای سرور، خطای دسترسی) تا بتونی راحتتر مدیریت کنی.
از مهمترین شرایطی که باید یک توسعه دهنده بک اند در API لحاظ کنه Custom Exception Handler هستش تا بتونه خطا ها رو با یک فرمت مناسب و یک دست پاسخ بده و این موضوع بر اساس کمپانی های مختلف متفاوت هستش ولی می تونین الگوی مناسبی رو از درونشون پیدا کنین.
مثلا داشتن کلید error در پیام و همچنین در ادامه status کد خطای اتفاق افتاده و همچنین جدا سازی detail و message که در یکی خطای توسعه و دیگری پیام قابل نمایش به کاربر قرار میگیره. در بعضی شرایط ممکنه حتی timestamp و اطلاعات بیشتری هم درج بشه مثلا code یا type که ممکنه شماره خطای خاص و یا کلید واژه مربوطه برای ردگیری خطای سریعتر باشه.
دیده میشه گاهی وقتا آدرس و یا حتی ورودی ها رو هم در بعضی سرویس ها نشون میدن که به نظرم جاش توی ریسپانس نیست و باید توی لاگ ها باشه و با این حال بعضی سرویس ها ارائه میدن.
نمونه Response مناسب برای خطا ها
{
"error": {
"status": 404,
"code": "OBJECT_NOT_FOUND",
"message": "آبجکت مورد نظر یافت نشد",
"detail": "Object matching query does not exist.",
"timestamp": "2025-10-03T12:30:45Z"
}
}
رفرنس ها:
- https://zuplo.com/learning-center/best-practices-for-api-error-handling
- https://api7.ai/learning-center/api-101/error-handling-apis
- https://nordicapis.com/5-real-world-examples-of-great-api-error-messages/
- https://www.baeldung.com/rest-api-error-handling-best-practices
📢 @thealibigdeli_channel
#api_design
#api
✍4❤1👎1
TheAliBigdeli Channel
مدیریت خطا و پیامها تو هر پروژهای خطا اجتنابناپذیره، مهم اینه چطور باهاش برخورد کنیم. اگه پیامها درست مدیریت نشن، هم کاربر گیج میشه، هم فرانت سختتر میتونه هندل کنه. چند تا نکته به عنوان best practice: - برای خطاها یه ساختار مشخص داشته باش تا فرانت…
نظر کانال https://t.me/PyBackEndHub
در مور این پست.
این پستو دیدم تقریبا هر Rest standard ای بود توش رعایت نشده :))
در خصوص ارور و integration داشتن خوب با فرانت اند؛
۱. همیشه سعی کنید از HTTP STATUS استفاده کنید. اگه ۲۰۰ میدین یعنی ریسپانس موفقیت آمیز بوده، حالا هرچی که اسمشو موفقیت آمیز میذارید. چون تقریبا تمام ابزار های telemetry (چه بک اند چه فرانت) بر مبنا همین کار میکنه. اینکه شما http status code رو بذارید تو بادی کار بسیار اشتباه و غلطی هست. استاندارد های http رو دور زدید.
۲. فرانتی که نمیدونه کی به سرور درخواست داده، دولوپر نیست. صرفا یک LLM ای هست با دسترسی به git. یک تایمی ارسال میشه از سمت سرور به کلاینت. حالا اگه این تایم استمپ زمان اتمام درخواسته بازم برای کلاینت مهم نیست که شما بخوای رو سرور بذاری. برای کلاینت مهم اینه که درخواست رو کی دریافت کرده که میدونه.
۳. اینکه شما پیام ترجمه شده رو سمت سرور نگه دارید یک اشتباه دیگست. code کافیه. داکیومنت شما باید تو OpenAPI برای ارور ها باید schema داشته باشه که فرانت بدونه چه ارور هایی ممکنه بیاد. اینطوری اگه فرانت از ابزار های code auto generate استفاده کنه (که مثلا schema openapi رو میگیرن و کلاینت میسازن خودشون) اون ارور هارو هم میبینه و تو تایپ سیستمش میاد. میتونه اونا رو حالا به هر زبونی که کاربر هست بهش نشون بده. میتونه هرجوری بخواد ترجمه کنه. OBJECT_NOT_FOUND هم به شدت کلید اشتباهیه. چون معلوم نیست کدوم آبجکت not found عه. درستش اینه مثلا BookNotFound.که فرانت بتونه ترجمه کنه.
اگه خیلی فرانت بخوای قشنگ کارو در بیاره (تو سورس کد خودم اینکارو کردم) یک هوک نوشتم useError. این هوک اگه ریسپانس ۲۰۰نباشه ریسپانس رو میگیره. و کدش رو مپ میکنه به زبون یوزر و ترجمه میکنه و بهش نمایش میده. اگه کدی هم وجود نداشت (مثلا اروری که واقعا catch نشده بود) اون موقع فال بک میشه به اینکه خطایی در سرور رخ داده و نمیدونم این خطا چیه :). این هوک من, به شما هم ErrorMessage رو میده. هم یک کال بکی میده که از react-toastify استفاده کرده و ارور رو toast میکنه برای شما.
پس هم میتونی بنویسی
const { errorMessage } = useError()
errorMessage(response)
و هم
const { toastError} = useError()
toastError(response)
@PyBackendHub
در مور این پست.
این پستو دیدم تقریبا هر Rest standard ای بود توش رعایت نشده :))
در خصوص ارور و integration داشتن خوب با فرانت اند؛
۱. همیشه سعی کنید از HTTP STATUS استفاده کنید. اگه ۲۰۰ میدین یعنی ریسپانس موفقیت آمیز بوده، حالا هرچی که اسمشو موفقیت آمیز میذارید. چون تقریبا تمام ابزار های telemetry (چه بک اند چه فرانت) بر مبنا همین کار میکنه. اینکه شما http status code رو بذارید تو بادی کار بسیار اشتباه و غلطی هست. استاندارد های http رو دور زدید.
۲. فرانتی که نمیدونه کی به سرور درخواست داده، دولوپر نیست. صرفا یک LLM ای هست با دسترسی به git. یک تایمی ارسال میشه از سمت سرور به کلاینت. حالا اگه این تایم استمپ زمان اتمام درخواسته بازم برای کلاینت مهم نیست که شما بخوای رو سرور بذاری. برای کلاینت مهم اینه که درخواست رو کی دریافت کرده که میدونه.
۳. اینکه شما پیام ترجمه شده رو سمت سرور نگه دارید یک اشتباه دیگست. code کافیه. داکیومنت شما باید تو OpenAPI برای ارور ها باید schema داشته باشه که فرانت بدونه چه ارور هایی ممکنه بیاد. اینطوری اگه فرانت از ابزار های code auto generate استفاده کنه (که مثلا schema openapi رو میگیرن و کلاینت میسازن خودشون) اون ارور هارو هم میبینه و تو تایپ سیستمش میاد. میتونه اونا رو حالا به هر زبونی که کاربر هست بهش نشون بده. میتونه هرجوری بخواد ترجمه کنه. OBJECT_NOT_FOUND هم به شدت کلید اشتباهیه. چون معلوم نیست کدوم آبجکت not found عه. درستش اینه مثلا BookNotFound.که فرانت بتونه ترجمه کنه.
اگه خیلی فرانت بخوای قشنگ کارو در بیاره (تو سورس کد خودم اینکارو کردم) یک هوک نوشتم useError. این هوک اگه ریسپانس ۲۰۰نباشه ریسپانس رو میگیره. و کدش رو مپ میکنه به زبون یوزر و ترجمه میکنه و بهش نمایش میده. اگه کدی هم وجود نداشت (مثلا اروری که واقعا catch نشده بود) اون موقع فال بک میشه به اینکه خطایی در سرور رخ داده و نمیدونم این خطا چیه :). این هوک من, به شما هم ErrorMessage رو میده. هم یک کال بکی میده که از react-toastify استفاده کرده و ارور رو toast میکنه برای شما.
پس هم میتونی بنویسی
const { errorMessage } = useError()
errorMessage(response)
و هم
const { toastError} = useError()
toastError(response)
@PyBackendHub
👍6👏1
اگه پایتون میخوای یاد بگیری و همیشه به این نتیجه میرسی که خب پایتون چی داره من یاد بگیرم؟ اینجارو ببین.
یه مجموعه بزرگ و خوبی از انواع ابزار ها و چیز های ساخته شده با پایتونه که بهت نحوه کد زدن و ایده های خوبی یاد میده
github.com/mahmoud/awesome-python-applications
✍🏻 @Linuxor
یه مجموعه بزرگ و خوبی از انواع ابزار ها و چیز های ساخته شده با پایتونه که بهت نحوه کد زدن و ایده های خوبی یاد میده
github.com/mahmoud/awesome-python-applications
✍🏻 @Linuxor
🔥3❤1
این کتاب جنگو ۵ با مثال
همین الان به دستم رسید
ترجمه کتاب
Django 5 by example, 5th.ed
هست
https://B2n.ir/uz8816
لینک فروشش از انتشارات پندارپارس، ترجمه یعسوبی
۳۰ صفحه اولش توی سایت انتشارات هست
کیفیت کاغذش خیلی خوبه
کیفیت چاپش خوبه
در مورد ترجمه و... به مرور اگه چیزی دیدم می نویسم
همین الان به دستم رسید
ترجمه کتاب
Django 5 by example, 5th.ed
هست
https://B2n.ir/uz8816
لینک فروشش از انتشارات پندارپارس، ترجمه یعسوبی
۳۰ صفحه اولش توی سایت انتشارات هست
کیفیت کاغذش خیلی خوبه
کیفیت چاپش خوبه
در مورد ترجمه و... به مرور اگه چیزی دیدم می نویسم
🤮16❤6🆒3👍2👏2