وقتی از chatGpt یا ابزارهای مشابه استفاده می‌کنید باید چندین برابر مراقب باشید.
متاسفانه این ابزارها شعور درستی ندارند؛ شاید مثل یک senior توضیح بدهند یا کد تمیز بزنند ولی درک درستی ندارند (برای همین من اصلا به نیروی
Junior, Mid-level
حتی پیشنهاد نمی‌کنم)

یک کد مشابه کد بالا باگی بود که توی کدهای پروژه پیدا کردم و چندروزی تیم رو هم درگیر کرده بود.

بنظرتون علاوه بر موردی که با print مشخص کردم چه باگ فاجعه‌بار تری توی کدهای بالا وجود داره ؟

پ.ن : chatGpt و باقی ابزارهای مشابه فقط برای وقتی خوبه که مثلاً یادتون رفته
پارامتر‌های ورودی فلان تابع فلان پکیج اسمش چی بود
در همین حد
نه اینکه منطق و نحوه حل مسئله رو بهش بسپارید

ینی این شرایط :
من میدونم چی رو با چه منطقی میخوام، ولی حال syntax زدن ندارم پس ازین ابزارها استفاده می‌کنم تا فقط و فقط
Syntax
رو بنویسه برام

ازونجایی که به جواب رسیدید
مشکل اینه که
lru_cache
و cache (پایتون ۳.۹ به بعد) رو نباید روی
method
ها بزنید داکبومنت‌های مختلف هم بهش اشاره کردند.
دلیلش هم که قبلا توی این پست گفتم :

Post Link

توی پست بعدی بیشتر توضیح میدم.

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

داخل کادر سبز کاری هست که واقعا lru_cache می‌کنه
مشکل اینه که حالا که میره توی global دیگه garbage collector روش اعمال نمی‌شه چون همواره رفرنس خواهد داشت

شاید بهتره توی این مثال

def __del__

رو هم بذارید و پرینت بزنید تا ببینید که اجرا نمی‌شه و این ینی garbage collector دست بهش نمیزنه

حالا راه حل چیه : (پست بعدی)

برای راه حل راهکار زیاد هست :
۱- کش رو برای هر instance جدا کنیم؛ توی نمونه‌ کدهایی که ما داشتیم این راهکار برامون مناسب بود.

۲- پردازش مربوط به این بخش که نیاز به cache داره رو کلا ببریم توی یک ماژول جدا و functional بنویسیم کدش رو

۳- بیایم از __new__ و meta class programming استفاده کنیم به همراه روش اول و اینطوری بین instance های مختلف هم می‌تونیم
cache
رو نگه داریم.

توی این تصویر من از راهکار اول استفاده کردم.

اینم سوال جالبی بود که از من شد (چند هفته گذشته ولی خب ...)

اگر قرار بود از اول شروع کنی، چه مطالبی رو دنبالش میرفتی ؟

قطعاً برای برنا‌مه‌ نویسی :
بجای اون همه جابجایی فقط ۳ تا زبان رو نگه می داشتم

Assembly, Rust, Python3

نکته اینه که من خیلی آدم سمت ترمینال و سروری هستم و بیشتر جذب این موارد میشم تا محیط گرافیکی و ...

قطعاً توی این مسیرم باز هم
Cisco CCNA, CCNP
رو میخوندم. (البته پیشنهادم برای برنامه‌نویس‌ها این روزها درحد همون CCNA هست)

قطعاً بازهم
Linux RedHat
رو آزمون‌هاش رو میدادم (مدرک lpic رو دوس ندارم چون خیلی کاغذی هست)

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


چرا Rust برای python کارها خوبه و تو چه شرایطی؟:
https://t.iss.one/pytens/801

نکته دوم : خود من اون زمان
C, C++
رو یاد گرفتم ولی الان برای آیندگان پایتون دولوپر
Rust
رو پیشنهاد دادم.

راجب پروفایلر که قطعاً ی روزی سر فرصت مطلب می‌نویسم و آموزش میذارم مثل مطلبی که در مورد

dis
نوشتم و نحوه تحلیل خروجی‌ پروفایلر‌ها رو خواهم گفت چون صرف اینکه فقط زمان اجرا رو بخونید، بهش
Profiling
نمیگیم؛ نکته‌ای که متأسفانه ۹۰٪ آموزش‌ها در همین حد بهش می‌پردازند.

اما تا اون زمان :
ابزاری که خودم استفاده می‌کنم توی این سال‌ها

Scalane Github

هست (تلفظ درستش: اِسکِیلین)
چراکه نه تنها برای Cpu بلکه
Memory, Gpu

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

Profiling
شاید بنظر مطلب خیلی سطح بالایی باشه و نیروی سطح پایین‌تر فکر کنه که نمی‌تونه ازش بهره بگیره
ولی اینطور نیست اتفاقا بیشترین کمک رو به نیرو‌های در مسیر یادگیری می‌‌تونه بکنه.

اهمیت این جدول خیلی بالاس،
بعضی وقت‌ها توی مباحث
Optimization
شرکت که وارد می‌شیم، (البته برای pipeline های پردازشی که سالی ۱ بار آپدیت می‌شوند و ۳۶۵ روز ۲۴ ساعت و ۷ روز هفته در حال پردازش دیتا هستند بدون تغییر حتی ۱ خط کد)

یک همچین جدولی رو از تیم سخت‌افزار تحویل میگیرم؛ توی بحث ما
Access Time
رو کاری نداریم (چون فقط نسبت سرعت مهم هست و همین که ترتیب رو میدونیم کفایت می‌کنه)
اما چیزی که اهمیت پیدا می‌کنه
Size
هست.

اگر بخوام اهمیتش رو ساده توضیح بدم، فرض کنید روی کدهاتون
Scalene
رو اجرا کردید و دیدید که
Cpu idle time
یا همون زمان بیکاری cpu زیاد هست، و فرض کنید شما دارید دیتارو توی ram استفاده می‌کنید.

فرض کنید سناریو realtime هست و این بخش حدوداً ۱۰ مگ دیتا در هر لحظه بهتون میده و این خیلی حجم زیادی هست وقتی روی دیتای متنی کار می‌کنید.

مشکل کجاست ؟ پست بعدی

@PyHints

مشکل اینه که خیلی از دوستان این حجم رو که می‌بینند سریع به load کردنش توی RAM فکر می‌کنند 10MB حجمی نیست، بعد کدهاشون رو تا جایی که توانش رو دارند Optimize می‌کنند و در نهایت هم وقتی نمی‌تونند بهبودش بدهند می‌گن

پایتون سرعت کمی داره

این موضوع قبول ولی بخشی ازین داستان برمیگرده به این موضوع که شما معماری سیستم‌ رو نمی‌شناسید و کاری رو قبول کردید که نیاز به این دانش داره

اهمیت جدول بالا هم دقیقاً همینجا هست، ی موضوعی که همیشه توی کنفرانس‌ها و مراسم معرفی CPU ها اعلام می‌شه سرعت
Compression, DeCompression
هست، که ۹۹٪ بهش دقت نمی‌کنند.

اما این نشون میده اگر من دیتای این مثال ینی ۱۰ مگابایت رو فشرده کنم و از cpu های نسل جدید هم استفاده کنم، می‌تونم دیتای فشرده شده رو وارد
L3 Cache
توی مثال بالا، کنم و بجای سرعت خوندن دیتای
100 ns
از سرعت خوندن داده
30 ns
بهره ببرم که خودش به تنهایی یعنی
1/3
شدن زمان، باقیشم بیخیال ...


قطعاً جدول بالارو توی همه‌ی کتاب‌های درسی و ... دیدید
اما از کاربردش هم اطلاع داشتید ؟
یا دلیل اینکه همیشه سرعت
compression, decompression
اعلام می‌شه رو چطور ؟

@PyHints

این باگ ۱ ماه تیم رو درگیر کرده بود :

توسعه و تست همزمان بصورت پارالل توی تیم‌هایی که هستم پیش میره (اگر تعداد نیرو کافی باشی)

یک بخشی از کد رو داریم که همه‌ی تست هارو به درستی پشت سر میذاره، حتی تست‌هایی که توی pipeline و CI/CD داریم

همه چیز حتی بصورت هفتگی روی سیستم ها درست کار می‌کنه
اما بمحض اینکه میره روی سرور تست‌ خصوصی یا
A/B test

سرعتش تا ۲۰ برابر کندتر می‌شه شایدم بیشتر
ولی این مشکل رو روی سیستم دولوپر‌ها نداریم.

پیدا کردن این مدل باگ‌ها خیلی سخت می‌تونه باشه، ولی خب بالاخره پیداش کردیم.

مشکل چی بود:

if item in mylist:

همین خط کد، ۲ تا مسئله داشتیم،
۱- نیروی junior ایی از طرف شرکت به تیم اضافه شده
۲- توی تیم DevOps هم چون کار روتین شده بوده، سپرده‌اند به یک نیروی Mid-level نگهداری رو

و همزمان ۲ تا خطا انجام شده :
۱- نیروی تیم توسعه و استفاده از in توی پایتون
۲- نیروی تیم DevOps و تبدیل یکی از pipeline های تست، ازش پرسیدند چرا انقدر تست طول می‌کشه بنده خدا رفته چک کرده دیده یک دیتاست بزرگ داریم برای تست
اومده این رو با یک دیتای کوچیکتر جایگزین کرده

و چون نیروی junior توسعه دهنده هم سواد کافی نداشته روی
mylist
توی مثال بالا برای چک کردن اینکه آیا یک نمونه‌ای وجود داره یا نه از
in

استفاده کرده، که روی حجم بالای دیتا منبع اصلی کند بودن هست :

راهکار :
۱- چون روی دیتاهای حجیم کار می‌کنیم، DevOps نباید دیتای تست رو تغییر میداد (اینجوری باگ خیلی زودتر خودش رو نشون میداد)

۲- نیروی تیم توسعه نباید از in و list استفاده میکرد :
۲-۱ : اول به این دلیل که ما اندیس داده رو نمی‌خواهیم فقط وجود یا عدم وجودش توی کدها مهم بوده که نوع داده‌ای set بسیار اینجا کمک کننده بود, همین که بدونیم ۱ مورد وجود داره برامون کفایت می‌کنه این یعنی فضای جستجو کوچکتر

۲-۲ : دستور in بطور کلی کند هست (برای list کوچیک خوبه) باید بجاش از الگوریتم‌ها و ساختمان داده درستش استفاده میکرد که Tree گزینه خوبی هست قطعاً.

دو تا اشتباه همزمان می‌تونه ۱ ماه همه‌ی تیم رو سردرگم کنه

نکته‌ی مهم :
حواستون باشه کجا از in استفاده می‌کنید و مهمتر اگر برای داده حجیم کد میزنید حتماً یکبار روی این حجم داده هم تست انجام بدید.

#خارج‌_از_بحث ولی لازم :

من تو زندگیم آدم‌هایی رو دیدم که از موفقیت می‌ترسند
از چشم خوردن یا ... موفقیت
یعنی انقدر می‌ترسند که ترجیح میدهند موفقیتی نداشته باشند، یا اینکه همه‌جا مخفی کنند و منکر موفق بودن یا شدن بشوند.

که این خودش باعث می‌شه کم کم افول کنند؛ دقیقاً همونطور که مولوی می‌گه :

شکر نعمت نعمتت افزون کند
کفر نعمت از کفت بیرون کند

حالا دلیل منطقی این قضیه چیه ؟
شبکه سازی، من و همه‌ی افرادی که میشناسم خیلی از موفقیت‌هارو مدیون شبکه آدم‌های اطرافمون هستیم، داستان پارتی‌بازی و ... نیستا (دهنمون سرویس شده)

ولی همونطوری که شما هیچوقت نمی‌تونی، آدمی که اصلاً نمی‌شناسی رو بعنوان پارتنر انتخاب کنی
توی کار هم آدمی که هیچوقت باهاش کار نکردی و کد زدنش رو ندیدی رو نمی‌تونی تایید کنی یا برای کار به شرکت معرفی کنی (اگر بد باشه، برای خودت هم بد می‌شه)

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

این بخشش برای تازه‌کارها ☝️☝️☝️

اما ی بخش دیگه هم هست، توی این هفته یکی از دوستانم توی ایران کار پیدا کرد با مبلغی که توی ایران واقعاً قفل هست.
۵ برابر دستمزد شرکت‌های خصوصی و اونایی که پرداخت خوبی دارند.

شبکه‌ی آدم‌های اطرافمون، خیلی تلاش داشتند که این موضوع رو تماماً گردن شانس بندازند (میدونم از نظر علمی اثبات شده ۵٪ شانس برای موفقیت ۱۰۰٪ لازم هست و شانس منطقی هست)

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

هیچکس زحماتش رو ندید، وقتی صحبت‌ها تموم شد واقعاً ناراحت بود
چون احساسش این بود که کسی تلاش‌هاش رو ندیده و کسی هم چشم دیدن موفقیتش رو نداره

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

باید بدونید قدم اول، شبکه سازی درست هست و برای شبکه‌ سازی درست باید خودتون رو ثابت کنید و موفقیت‌ هاتون رو نشون بدید.

و برای اونایی که میگن خوش بحال فلانی که ماهی ۱۰۰-۲۰۰ میلیون یا بیشتر در میاره، کاش منم می‌تونستم و ... باید بگم :

فلانی از خیلی چیزا، تفریحات و ... گذشته تا به اینجا رسیده شما که از مهمونی هم نمی‌گذری بیخود می‌کنی حرف شانس میزنی

برای اون افرادی هم که به موفقیت رسیدن (حتی پله‌های اولیه) :

no one knows the price you paid, so don't care.

@PyHints

#Quick

من این اخطار‌ هارو همیشه زودتر به دوستان نزدیکم میگم
گفتم ازین به بعد بعضی‌هاش رو اینجا هم بگم:

اولین :

asyncio
رو هرچه زودتر یاد بگیرید، پترن‌ها و مفاهیم برنامه‌نویسی
Async, Parallel, Concurent

قبلتر تأکید زیادی روش نداشتم، اما دیر نیست (توی ایران) روزی که حتی
Intermediate python

هم توی مصاحبه باید این مفاهیم رو کامل بدونه.

@PyHints

Guido Van Rossum
رو قطعا دیگه می‌شناسید (خالق پایتون) امروز یک بحثی دیدم مخالف ایشون و تصمیماتی که گرفته و تاثیراتی که گذاشته روی
Cpython
نمیخوام وارد جزئیات بشم ولی بیشتر بحث راجب mojo بود و پستی که گذاشتم راجب تصمیمی که گرفتند و Typing رو تبدیل به ماژول کردند بجای اینکه بیان ی زبان برنامه‌نویسی (اشتباه) یا یک interpreter دیگری برای پایتون ارائه بدند.

mojo

رو نمیدونم خالق‌هاش بهش زبان برنامه‌نویسی گفتند یا طرفدارهاش ولی خب این اولین بار نیست :
Jython, IronPython, IntelPython, ....
این موارد هم هدف‌هایی مثل mojo دارند ولی فقط جامعه خاص یا پروژه خاص سراغش میره.

من این مورد رو توضیح دادم و برگشتیم سر بحث قدیمی پایتون و کوبیدن پایتون ...
GIL (global interpreter lock)

شاید باورش برای تازه‌کار یا تخریب گر سخت باشه ولی همین هم یکی از بهترین تصمیمات
Guido Van Rossum
بوده؛ خیلی از افراد این موضوع رو باور نداشتند و تلاش کردند جایگزین ارائه بدند و نشون بدند که خالق پایتون اشتباه کرده که خب نتیجه مشخص هست تماما همگی شکست خوردند اما این وسط یک پروژه‌ای وجود داره که هدفش donate به جامعه پایتون هست و نه تخریب وضعیت این پروژه هم شکست هست فعلا اما درس‌های زیادی داره اگر دوست داشتید بدونید چرا من از GIL حمایت می‌کنم این لینک رو بخونید :
Project GILectomy state

Larry Hasting
وقتی نهایتا موفق شد GIL رو جایگزین کنه؛ تست های مقایسه‌ای انجام داد و نتیجه‌اش شد این :
"With his complicated buffered-reference-count approach he was able to get his "gilectomized" interpreter to reach performance parity with CPython, except that his interpreter was running on around seven cores to keep up with CPython on one."

به توانایی Cpython رسید ولی روی ۷ هسته پردازشی درحالی که Cpython همون کار رو روی ۱ هسته انجام میداد.
در نهایت اینکه پروژه Gilectomy با ایده‌های جدید همچنان درحال توسعه هست؛ اما همونطور که خالق پایتون گفته بود اگر قرار بود از GIL استفاده نشه و منتظر بمونه شاید هنوز پایتون رو نداشتیم.

@PyHints

دوستان اگر یک جایی توی پست‌ها اشتباه تایپی می‌بیند
نه برای املا فارسی

بلکه اشتباها چیز دیگری تایپ شده

مثلاً صحبت از
Concurrency, Parallelization
بوده و به اشتباه بجای کلمه
Concurrent
از کلمه
Parallel
استفاده شده.

این رو پای دوتا موضوع بذارید :
۱- خستگی
۲- اینکه من وسط نوشتن این متن‌ها، خیلی وقتا برام تسک پیش میاد که اولویت اول روی تسک‌های شغلم هست

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

سپاس از شما🌹 (خود این تشکر هم باگ داشت درست شد)

من عاشق این نوع پست‌ها هستم؛ حتی اگر توش کمی اشتباه هم باشه
پست آموزشی خوبه، ولی پستی که از ارورها و خطاها و مشکلات بگه فوق‌العاده هست ...

داستان اینه که این پست‌ها نشون میده چطور میشه از اشتباهات دیگران درس گرفت و بجای تجربه کردن شکست از شکست افراد دیگه درس گرفت.
حالا ی وقتایی این پست در حد مشکلات یک پکیج هست یک وقتایی توضیحات کل مشکلات پروژه
مثلاً : discord و مشکلش با mongodb و جابجایی به Cassandra که چندسال قبل ارائه جامعی رو راجبش داشتند و ...
بطور کلی سعی کنید این مدل پست‌ها رو دنبال کنید.


اینجا هم راجب Celery و مشکلاتش صحبت کرده، راه حل بعضی هاش رو هم گفته :

Problems with Celery

#Quick

برای دوستانی که تازه میخوان یاد بگیرند این موضوع رو خیلی مهمه که روی پایتون 3.9 به بعد تمرین کنید و یاد بگیرید این موضوع رو
برای همین کتابی که توی پست pin شده معرفی کردم رو فقط تایید می‌کنم نسخه پایتون اون کتاب 3.10 هست با تغییرات و باگ‌های رفع شده آموزش میده.

برای اوقات فراغت و روزهای تعطیلاتی که داریم، از همین فردا و تا آخر ماه

PyCon 2023 Salt lake city US.

مثلاً یکی از مواردی که خودم به شخصه پاش خواهم نشست یک
Pydantic V2
و اینکه چطور از Rust برای افزایش سرعت استفاده می‌کنه هست، چون FastApi هم ازش پشتیبانی می‌کنه تو ورژن آخر که سرعتش رو خیلی بهتر کرده.


نکته این ویدئوها ضبط شده هست (کنفرانس قبلتر بود و فکر می‌کنم همون موردی هست که خالق
FastApi
و Guido بعدش باهم ملاقات و صحبت داشتند.)

@PyHints

پ.ن : پیشنهاد نمی‌کنم همه‌ی ویدئوها رو همه ببینند، بسته به سطحی که دارید یا موضوعی که کار می‌کنید ویدئو مناسب رو ببینید.

این رو شاید بهتر بود توی کانال هوش مصنوعی بزنم تا اینجا
اما چون پیام‌های زیاد از درخواست برای
Roadmap
متخصص هوش مصنوعی شدن دریافت می‌کنم (توی کانال @pytens پیام‌های پین شده هست) گفتم شاید بهتر باشه اینجا راجبش صحبت کنم :

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

اگر واقعا دنبال کار ریموت یا مهاجرت هستید (که بسیار هم کار خوبی می‌کنید) هوش مصنوعی و دیتاساینس رو حتی اگر با تمام وجود بهش علاقه دارید بذارید توی اولویت دوم؛ برای پایتون برید سراغ :
1- Software Engineering
2- Backend Development

علاوه بر اون این ۲ مورد توی کارهای هوش مصنوعی هم خیلی بدردتون خواهد خورد.

شخصا باوجود همکاری های دلاری که داشتم اوضاع رو خیلی خوب نمی‌بینم؛ و درحال حاضر بهترین و راحت‌ترین راهای پیشنهادی و درآمدی دلاری که برام وجود داره آموزش دادن هست (که من اصلا آدمش نیستم؛ دوست ندارم برای آموزش دادن موضوعات پایه از کسی پولی دریافت کنم) و ۹۰٪ پیام‌های درخواست همکاری که توی لینکدین دریافت می‌کنم مربوط به شرکت‌های برگذار کننده دوره‌ی آموزشی هست.

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


پ.ن : هرچی به شهروندی نزدیکتر، شرایط راحت تر

#مزخرفترین_سرویس_دهنده‌‌های_ایرانی

این پیام رو پین می‌کنیم که دوستان حواسشون رو جمع کنند از کی میخوان سرویس بگیرند.

۱- ابرآروان :
down
شدن دائمی ( اکثر مواقع ۱ تا ۶ صبح بوقت تهران)، بخصوص برای ip خارج از ایران

عدم دسترسی به داکر ‌هاب
سرعت کند، برای دانلود از سرورهای خارج از ایران
سرعت کند (کیلوبایت) برای دانلود پکیج‌های
Python, nodejs

هزینه بالا با وجود افت کیفیت

۲- آسیاتک
Down
شدن سرویس؛ در حد ۱-۴ ساعت در ساعات انتهایی شب (داخلی و خارجی)
عدم دسترسی به داکر
سرعت متوسط دانلود از سرویس‌های خارج از ایران
سرعت متوسط دانلود پکیج‌های
Python, Nodejs

۳- ایران سرور
عدم دسترسی به داکر
سرعت متوسط برای دانلود از سرویس‌های خارج از ایران
عدم دسترسی برای دانلود پکیج‌های
Python, Nodejs

درصورت استفاده از ابزارهای مثل شکن و fod و ... دسترسی خواهید داشت اما سرعت دانلود در حدود
۱۰ کیلوبایت بر ثانیه خواهد بود.

هنگام فعال سازی سرویس به خطا هم خورد، که حل مشکل و ایجاد دسترسی حدوداً ۱۰ ساعت وقت برد (کارشناس‌های خودشون حل باید می‌کردند)


شما هم اگر سرویس دهنده مزخرف می‌شناسید لطفاً زیر همین پست اشاره کنید، اگر سرویس دهنده خوبی هم میشناسید کامنت کنید لطفاً 🌹

پ.ن : اگر جایگزینی هم برای
fod proxy, shecan, ...
می‌شناسید، زیر همین پست کامنت کنید.

ایران سرور ۲۰ دقیقه و تا اینجا تونسته
۲۵ مگ از
python dependency
هارو دانلود کنه؛ رکورد شکنی عالی هست.
هیچکس هم تیکت جواب نمیده؛ باز ابرآروان و آسیاتک حداقل میزدن در دست بررسی هست.

بیاید مزخرف‌ترین سرویس دهنده رو فعلا بدیم به ایران سرور

پ.ن : سرعت دانلود
20.6 kB/s

#ایرانـسرور #ایران_سرور

پ.ن : سرویس عودت وجه ایران سرور هم کار نمی‌کنه 😂🤣

به هیچ وجه سراغ این سرویس دهنده نرید.

یک دوستی دیروز راجب لاگ نویسی توی پایتون سوال داشت من به اینصورت براش توضیح دادم گفتم شاید مفید باشه :

Python logging components :

 1- Loggers

وضعیت لاگ؛ همیشه لازم هست.
نشون میده هر دسته از لاگ رو چطور باید باهاش برخورد کرد بطور کلی ۵ دسته بندی برامون خیلی مهم هستندکه به ترتیب از محیط توسعه و اطلاعات بیشتر به سمت محیط پروداکشن و وضعیت خطرناک تر میریم :
debug - info - warning - error - critical

معمولا روی محیط توسعه از debug استفاده میکنیم و روی محیط پروداکشن شخصا ۲ تا نسخه نگه میدارم یک نسخه که روزانه پاک میشه (به این وضعیت اتومات حذف شدن هم logrotate گفته میشه اصطلاحا) و یک نسخه هم که ماهانه rotate میشه ولی تا ۱ سال گذشته رو نگهداری میکنیم.
نسخه روزانه فقط اطلاعات سطح info رو نگهداری میکنه؛ بیشتر برای این نگهداری میکنیم که بدونیم چه کسی؛ چه زمانی؛ چیکار کرده ؟
نسخه ماهانه اما جاهایی هست که
warning - error - critical
داشتیم؛ ی وقتایی ممکنه از لاگ info برای warning استفاده بشه : برای مثال ممکنه یک یوزر با رفتار امن شروع کنه به درخواست زیاد فرستادن به یکی از لاگین ها اینجا جایی هست که میشه لاگ info رو بررسی کرد و اطلاعات اون یوزر رو توی warning هم داشت
اما بطور کلی warning , … خطاهای نرم افزار رو لاگ میکنه مثلا اگر سرور ارور 500 برای کاربری فرستاد تحت چه شرایطی و به چه دلیل این اتفاق افتاده و …
2- Formatters
از قدیم گفتن لاگ بدون فرمت بدرد صاحب کد هم نمیخوره؛
توی اکثر سناریوها لاگ ها بعد از یک مدت بصورت اتوماتیک بررسی میشن و تحت شرایطی خاص به ادمین سرور یا توسعه دهنده یا … هشداری رو ارسال میکنند پس اینکه چه اطلاعاتی به چه صورتی نوشته بشه مهم هست و وظیفه formatter هم دقیقا همین هست. مثلا :

warning sample.py unauthorized requests to resource at 2023-06-20 17:16:15 from 192.168.1.5 response code 401

 3- Handlers

بطور کلی مشخص میکنه با هر پیام لاگی که میاد چیکار باید کرد ؟ اینکه برای info فایل جدا داشته باشیم یا یک سری از اطلاعات رو داخل کنسول / ترمینال نمایش بدیم و … توسط ایشون انجام میشه
بعنوان مثال روی پروژه‌های مهم لاگ‌های سطح critical رو بصورت ایمیل یا پیامک برای چند شخص می‌فرستیم تا سریعتر بررسی بشه و این کار توسط Handler انجام میشه

 4- Filters

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

بنظرم دونستن اهمیت این ۴ تا کامپوننت؛ برای لاگ نویسی از هرچیزی مهمتر هست.

@PyHints