روی این مورد از من راهکار خواستن (جلوتر مثال میزنم برای توضیح)

همین اول کار بگم یک فرمول ثابت برای همه وجود نداره هرکسی گفت وجود داره کلاش هست .اگر فرمولش ثابت بود؛ برای همه بچه مدرسه‌ای ها و دانشجو‌ها استفاده میکردن که همه بتونند به درستی از تمام ظرفیت هوش و استعدادشون استفاده کنند.

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

کدوم یک از شما تو کدی که باگ و مشکل نداره؛ دنبال تغییر الگوریتم هستید ؟ پس پیدا کردن مشکل خودش ۷۰-۸۰٪ رسیدن به راه‌حل هست.

درنهایت من با این مثال توضیج دادم؛ فکر کردم شاید مفید باشه هرچند یک جلسه لایو ویدئویی می‌تونست بهتر باشه :

مثلا:
فرض کن داکیومنت
FastAPI
رو داری میخونی؛ نمیری بشینی توضیح نحوه نوشته شدن
generator
رو بخونی؛ موارد مهم رو میخونی مثل get, post, route, authentication , ...

یعد میای می‌بینی نوشته
Async
و تو میدونی لازم داری توی تمام پروژه‌هات مهم هست
چیکار می‌کنی از روی دامکیومنت Fastapi میخونی ؟
قطعا نه؛ میری یک کتاب یا یک دوره براش پیدا میکنی که هدفش فقط همین باشه

حالا فرض کن کتاب Async رو میخوای بخونی؛ توی ۳ فصل اول هم مقدمات پایتون هست
میشینی از اول بخونی ؟
نه فقط نگاه به سرفصل میکنی و اگر همرو میشناختی حذف میکنی و از فصل ۴ شروع میکنی

یک مثال دیگه کتاب fluent هست؛ این کتاب و کتابهای مشابه هر فصل یک هدفی داره
شاید داخل یک فصل اومده مثلا فریمورک django رو مثال زده
اینجا بر خلاف مثال قبلی
Async , FastAPI
شما نباید بری django رو بخونی اول به هدف فصل نگاه میکنی مثلا
mixin (multiple inheritance)
هست و بعد سعی میکنی همین رو درک کنی حالا اگر نویسنده کتاب زحمت کشیده ی مثال هم زده و شما بلد نیستی نباید برات مهم باشه

چون اون مثال میشه حاشیه برای شما؛ چون تو اصلا بکند دولوپر نیستی.

Elon musk on X

SpaceX just achieved peak download speed of 17Mb/s from satellite direct to unmodified Samsung Android phone

.

پ.ن :
نمی‌دونم دقت کردید، ولی همین سرعت پایین اینترنتی که ایلان ماسک و ... هم ازش رضایت ندارند.
از سرعت سرورهای برج میلاد هم بیشتره (بهترین سرورهای داخلی، با بیشترین سرعت اینترنت) 🤣😂

#Quick


نوشتن list اطراف هر تابع باید دوبار بهش فکر کنید. اگر اون تابع یک generator باشه شما دارید بدترین کار ممکن رو می‌کنید.

این مورد رو بین بچه‌های دیتاساینس و هوش خیلی زیاد می‌بینم و بین بچه‌های بکند هم وقتی دارند روی CSV, Json و یا Json-line کار می‌کنند.

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

مشکل دارن با ما؛ ما اینجا زحمت می‌کشیم generator می‌نویسیم بعد اینا سریع می‌ندازنش توی list

تصویر ی نمونه خیلی ساده برای مثال هست (زمان اجرا کامنت شده)

#تجربه

فریمورک برای یادگیری core python نیست،
سورس کد خوندن برای بهتر شدن هست نه یادگیری.


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

نشسته بودم سفارشم آماده بشه (قهوه نخوردم، چون dark roast داشت فقط) دیدم توی فضایی جداگانه کنار من (مثل بخش vip) یکنفر درحال آموزش دادن
generator, yield, yield from
هست، البته برای دیپ‌ لرنینگ و از روی فریمورک، متوجه شدم خیلی داشت اشتباه توضیح می‌داد.

بعد از چند دقیقه که حواسم به کلاس اونها بود و مدرس حواسش به من، کلاس‌ ۵ دقیقه استراحت داد و متوجه شدم از اون ۱۲-۱۵ نفر ۳-۴ نفر عضو همین کانال هستند و مدرس و باقی اعضا همه رفیق هستند که دارند تلاش می‌کنند باهم یاد بگیرند.

خداییش خیلی خیلی لذت بردم (کامیونیتی اینجوری لذت بخش هست) و توی این بحث و اینکه چطوری data loading, batching, ... توی فریمورک‌های هوش مصنوعی کار‌ می‌کنه مونده بودند و اشتباه این بود که بجای درک مطالب اصلی و عملکردشون سعی داشتند از framework این موضوع رو یاد بگیرند.

چندتاشون سوال پرسیدند و براشون توضیح دادم، بعد دعوت کردن این مبحث رو توی کلاس آموزش بدم.
منم که منتظر تماس بودم، شروع کردم با پایتون کد زدن و آموزش دادن و تأکید کردم این چیزا رو نباید با فریمورک یادگرفت هدف هرچی که باشه

ولی واقعاً دیدن همچین کامیونیتی‌هایی لذت بسیار زیادی داره، یادگیری رایگان و دردسترس برای همه.

یک توضیح کوچک راجب یوتیوب بدم، چون خیلی سوال شد.

قرار بر همکاری با یک video editor بود و خوب هم داشت پیش میرفت
ایده ساخت انیمیشن بود، و بعد از تست دوتا مبحث دیدیم که بهترین کار همین هست چون به خوبی مطالب رو انتقال و نمایش میده

حدوداً ۵ موضوع، ویدئو نزدیک به ۲۰ دقیقه آماده شده بود که متأسفانه ایشون تصمیم گرفت ویدئو‌ها رو به بنده نده و ایده رو خودش ادامه بده و شاید تدریس بکنه.
هرچند حتی اگر اینکار رو بکنه هم من ناراحت نیستم چون هدفم آموزش بود.

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

ایده انیمیشن رو ندارم دیگه (هر ویدئو تقریباً ۲ هفته کار برد)، اما سعی دارم از کد برای ساخت تصاویر استفاده کنم که مفاهیم راحت‌تر منتقل بشه و هر زمان خالی که داشته باشم روی این موضوع کار می‌کنم (یادگیری خودم و ساخت ویدئو)

این یکی واقعاً برام سوال هست،

دوستان سنیور، چطور میشه به یک نیرو منبعی رو معرفی کرد برای
Design Pattern

چیزی که زیاد می‌بینم اینه که خیلی از بچه‌ها، مطالب مربوط به design pattern رو می‌‌دونند و تعاریف و مثال‌ هارو به خوبی از پسشون بر میان (هرچند عمرا نمی‌بینید من تو مصاحبه تعریف چیزی رو بپرسم)

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


شخصاً هنوز کتاب یا دوره آموزشی ندیدم که
Design Pattern
هارو به خوبی و با چندتا مثال کد توی دنیای واقعی نشون بده.


نرید
Gang of Four
رو برای من بیارید که شرط می‌بندم یکبارم نخوندید 😑

من این مورد رو برای توسعه دهنده‌های پایتون می‌خوام و با مثال واقعی.

به بهانه 4k شدن کانال


I've Got You Under My Skin
Artists: Ben L'Oncle Soul
Album: Under My Skin
Released: 2016
Genres: Classical Soul

#flac

این روش log نوشتن برای پروژه کوچک خوبه که تعداد request کمی هم داره،
برای پروژه بزرگتر یا فریمورک و ابزارهای دیگه اصلا این روش توصیه نمی‌شه

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

گفتم بهتر توی کانال هم بصورت نوشتاری بذارم

سری پست‌های این هفته در مورد logging خواهد بود.

یکی از دوستان زنگ زد؛ میگه نمیشه زودتر بگی داستان چی هست دارم لاگر پروژه شرکت رو می‌نویسم؛
کل منبع صحبت‌های این هفته :
Logging Cookbook, python documentation

این صحبتم که میگن داکیومنت خوبی نداره و ... هرکی گفت بهش بگید : چون درست نخوندی.
اگر شما هم مثل ای رفیق من خواستید زودتر شروع کنید به خوندن؛ توی داکیومنت بالا چندتا log handler رو حتما بهش توجه ویژه کنید.

RotatingFileHandler, QueueHandler

قبلا صحبت شده راجب اولی؛ دومی هم برای multi thread کردن هست که لاگ نویسی باعث کند شدن پردازش نشه.
StreamHandler, SMTPHandler, SocketHandler
توی این ۳ مورد هم مورد اول داخل داکر بدرد بخور هست؛ smpt رو هم احتمالا حدس زدید برای ارسال ایمیل هست (معمولا لاگ‌های critical رو برای خودمون یا ادمین یا ... ارسال می‌کنیم) و در نهایت هم SocketHandler که برای ارسال لاگ با پروتکل tcp به سرور دیگری استفاده میشه که خیلی خیلی مهم هست (باور ندارید از بچه‌های امنیت بپرسید)

معمولا خود من از این ۵ مورد توی پروژه‌های بزرگ استفاده می‌کنم؛ البته خیلی وقتا شرکت‌ها SocketHandler نمیگرین و براساس event یا ساعتی یا ... بکاپ لاگ فایل رو به S3 bucket میفرستند روی آمازون که هزینه کمتری داره برای نگهداری.

#یادم_باشه

حتماً یادم باشه نوشتن
Log filter
کاستوم رو یاد بدم،

شرکت با یکی از شرکت‌های خدمات دهنده اروپایی قرارداد بسته
و برای تست قرار شد، ۱ هفته یک کپی از دیتاهاشون رو بفرستند سمت log server ما.

شاید باورتون نشه، ولی تمامی شماره‌های مشتری‌ها بدون اینکه حتی بخشی از شماره‌ها مخفی بشه بصورت کامل داخل Json log ها هست.

یکی اینجا استفاده از logging رو بلد نبوده 😁


پ.ن : توی پست‌های بعدی آموزش داده شد.

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

اصلی ترین عنصر logger هست؛ اگر بخوام خیلی خلاصه بگم:
وظیفه‌اش اینه که یک پیام از شما دریافت کنه و بر اساس level اون رو به handler درستش ارسال کنه.

با این تعریف عنصر بعدی که راجبش صحبت می‌کنیم handler هست.
وظیفه‌اش ارسال لاگ به مقصدی هست که براش تعریف شده.

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

formatter
اینکه چه اطلاعاتی توی لاگ فایل (علاوه بر پیام شما) بصورت خودکار قرار بگیره و اینکه این اطلاعات چطور نمایش داده بشه همش وظیفه این عزیز دل هست.

filters
وظیفه فیلتر کردن لاگ‌ها رو داره؛ چه اینکه نوشته نشه یا تغییراتی روش انجام بشه و بعد نوشته بشه.

استیج آماده شد؛ بریم سراغ مثال تصویر
استفاده از logging.basicConfig چیزی نیست که برای پروژه‌های مهم و بزرگ بخواید داشته باشید؛ چون معمولا بیش از ۳ مورد handler خواهید داشت که این یعنی تعداد زیادی logger که هرکدوم formatter, filter های خودشون رو خواهند داشت.

ادامه پست بعدی ....

source code

برای همین گزینه بهتر استفاده از logging.config.dictConfig هست؛ این تابع تنظیمات رو بصورت dictionary از شما تحویل میگیره و logger رو برای شما میسازه.
همینجا بگم؛ توی سورس کدهای مختلف ممکن هست که این کانفیگ‌ها (دیکشنری) رو توی فایل‌های json, yaml, ini نوشته باشند؛ اما شخصا موقع نوشتن کد سعی می‌کنم مستقیم اینکار رو انجام بدم (داخل py). دروغ چرا مغزم رو درگیر حفظ کردن کلیدهای دیکشنری نمی‌کنم و اینطوری خود vscode کلیدهای موجود رو بهم میده اما راجب config مثال بالا که خیلی خیلی ساده هم هست.
اول از همه version فعلا فقط 1 وجود داره (ورژن دیگه اومد همدیگر رو خبر می‌کنیم)؛ disable_exisiting_logger اگر True بذارید هر لاگر دیگه‌ای که توی این کانفیگ نیست غیرفعال میشه ۹۹٪ موارد روی False بذارید.
موارد بعدی یعنی filters, formatters رو برای این مثال کاری نداریم (ساده شروع کنیم و کم کم بهش برسیم).
و اما handlers؛ اولین چیزی که براش لازم هست اسمش میشه (باید بدونیم چی صداش کنیم) که توی مثال بالا من اسمش رو گذاشتم console چون قراره لاگ هارو توی ترمینال نمایش بده؛ توی خط بعدی یک کلید داره به اسم 'class' اگر قرار بود از Handler‌هایی که خود ماژول logging یا ماژول‌های دیگه براتون فراهم می‌کنند استفاده کنید از کلیدواژه 'class' استفاده میشه و مقداری که بهش میدید کلاسی از اون ماژول هست و باید قابل import باشه توی این مثال من StreamHandler رو استفاده کردم یعنی شما می‌تونید ی جایی تست کنید :

from logging import StreamHandler

مورد بعدی stream این کلید ثابت نیست؛ دلیلش هم واضح هست (حداقل برای من) هر کلاس یک سری پارامتر ورودی مختص به خودش داره StreamHandler هم توی ورودی می‌تونه یک کلید به اسم stream دریافت کنه که البته optional هست؛ یعنی حتی اگه توی مثال بالا این خط کانفیگ رو پاک کنید بازم کار می‌کنه ولی بصورت دیفالت مقدارش روی sys.stderr تعریف شده که تحت شرایطی ممکنه نخواهید اینطوری باشه پس می‌تونید تغییرش بدید. که من گفتم از ماژول sys و stdout یا همون standard output استفاده کنه و خروجی اینجا نمایش بده ( اگر فرق stdout, stderr رو نمی‌دونید؛ ی ذره لینوکس بخونید )
ولی داستان

ext://

اولش چیه پس ؟ هیجی فقط بهش میگه که این مورد رو از یک ماژول external باید بگیری (لازم بود برو import کن).

در نهایت logger؛ مثل مورد قبل اولین مورد اسم هست این اسم مثل handler دلبخواهی نیست؛ و بهتر اسم بالاترین سطح پوشه‌ای باشه که این لاگر براش تعریف می‌شه؛ من اسم پروژه‌ام رو گذاشتم pyhints و این پوشه رو تبدیل به یک ماژول / پکیج کردم و می‌خوام برای تمام py فایل‌های داخلش از این logger بتونم استفاده کنم. برای همین هم اسم logger ام رو pyhints گذاشتم. توی ساده ترین حالت شما نیاز به دوتا کلید دارید؛ اولیش level که من اینجا گفتم مثلا از یک فایل .env پروژه میخونم (پیاده‌سازیش تمرین برای شما) و اگر توی محیط develop نبودم نمی‌خوام لاگ‌های debug دیده بشه فقط از info به بالا رو قبول کن.
کلید بعدی یعنی handlers لیستی از handler هارو میگیره و اگر یک لاگ مسیج هر دو شرایط رو داشت (هم از پکیج pyhints بود؛ هم level بالاتر از آنچه توی خط قبل تعریف شده داشت) اون موقع اون پیام رو برای handler ها می‌فرسته تا کار درست رو باهاش انجام بدند.

حالا فقط کافیه توی کل پروژه یکبار این تابع صدا زده بشه تا logger ما تنظیمات اختصاصی خودش رو دریافت کنه؛ اتفاقی که توی مثال بالا توی خط 30 داره میوفته.
خط 32 اما خیلی مهمه دارم میگم برو ی لاگر برام بیار اسمش رو بذار pyhints.log_config اینجا به عمد ی همچین اسمی دادم تا نشون بدم چقدر اسمی که برای logger انتخاب می‌کنید مهم هست؛ اما توی کدها و پروژه‌هاتون از __name__ استفاده می‌کنید ( درصورت import همین فرمت اسم رو می‌سازه که من بهش دستی دادم).
اینجا logging نگاه می‌کنه که کانفیگ اختصاصی داریم که logger ایی به اسم pyhints داخلش تعریف شده و ماهم توی درخواست getLogger اسمی دادیم که اگر با . جداسازی بشه pyhints بخش بالاتر هست پس این دو مورد باهم مچ میشه و می‌تونه از این لاگر خاص برای اسکریپت فعلی استفاده کنه حالا متغییر logger از تنظیمات pyhints.logger استفاده خواهد کرد برای نمایش log messages داخل ترمینال.

من سعی کردم خیلی ساده توضیح بدم؛ تا همه این موارد رو متوجه بشوند (این رو درک کنید و البته جایگاه هرکدوم رو) ۷۰٪ کار حله.

امیدوارم مفید باشه. 🌹

نکته بعدی تنظیم formatters هست؛ همیشه سعی می‌کنیم ساده شروع کنیم.
برای مثال توی این کد (ادامه کد قبلی) من یک فرمتر استاندارید اضافه کردم.
همیشه سعی می‌کنم توی فرمترهایی که می‌نویسم چندتا فیلد رو داشته باشم :
1- asctime
اون 10s بغلش برای اینه که میخوام حتما اندازه ۱۰ کاراکتر فضا داشته باشه حداقل توی levelname بهتر خودشو نشون میده
2- levelname
باید بدونیم وضعیت لاگ چطوری هست؛ لاگ debug, info چیزی نیست که روزانه بخواید چشمتون بهش باشه
3- name
برای اینه که بدونیم لاگ از کدوم اسکریپت اومده؛ راحتی خودمون هست.
4- lineno
این مورد رو توی کدهای نیروهام نبینم؛ merge نمیشه
داستان اینه که ترکیب این مورد و اسم فایل من رو دقیقا میبرم روی تابع / متد یا ... ایی که باعث خطا شده.
5- message
اصل جنس هم اینجاس پیامی که باید ارسال بشه
باقی موارد هم برای قشنگیش هست.

اما چرا دروغ؛ شمارو نمیدونم من چشمام اینطوری اذیت میشه یک سری لاگ سفید روی پس زمینه سیاه خوندنش برام سخت هست.

تنها هندلر تعریف شده براش چون console هست درخواست به handlers و console ارسال میشه و اینجا کلاس تعریف شده براش rich هست (برای همین خروجی توی کنسول همچنان رنگی هست) و برای فرمت لاگ handlers درخواست رو باید برای formatters و بطور خاص file ارسال کنه. قشنگی داستان اینجاس که file از کلاس
pythonjsonlogger.jsonlogger.JsonFormatter
استفاده می‌کنه من بازم فرمت datetime رو استاندارد کردم و فرض کردم تعداد درخواست های به سرورم زیاد و در حد هزارم میلی‌ثانیه هست برای همین
%(msecs)03d
یعنی تا هزارم میلی ٍثانیه رو هم اضافه کردم.
خط آخر یعنی format خیلی باشعور هست python-json-logger میگه تو فقط به من بگو چی رو لاگ بندازم فرمت معنی نداره من از اون مقدار بعنوان key استفاده خواهم کرد؛ و چیزی که برای اون میاد رو value در نظر میگیرم.
لیست کامل این موارد رو روی داکیو.منت logging می‌تونید بخونید و حتی می‌تونید format خودتون رو هم تعریف کنید (مثلا شماره موبایل رو جدا بگیره) اما حواستون باشه حتما باید json serializable باشه.


توی مثال بعدی fileRotate رو میگم که بسیار استفاده میشه؛ و بعد هم یکم کاستوم کلاس برای فیلتر می‌نویسیم که شماره موبایل اگر توی لاگ بود بصورت کامل نمایش داده نشه
همون باگی که گفتم دولوپرهای اون شرکت داشتند.

ازینجا به بعدش رو دوس دارم (الان در سطح مدیور این پکیج رو میشناسید.)
اولین حرکت؛ به pyhinst logger گفتم اگر درخواست log برات اومد. باید برای دوتا هندلر بفرستی؛
1- console
2- file
کنسول رو همیشه نگه میداریم برای داکر که راحت باشیم؛ فایل رو برای شرکت‌های قدیمی‌تر که بکاپ زمانی یا توی مثال بر اساس حجم نگه می‌دارند.

تغییر بعدی که داره اضافه شدن file به handlers هست.
اول از همه؛ گفتم کلاسش باید
logging.handlers.RotatingFileHan
dler
باشه؛ جلوتر میگم معنی Rotate File چی هست (قبلا هم مثال زده بودم البته)

توی خط بعدی بهش گفتم که فقط لاگ‌های سطح warning یا بالاتر رو توی فایل بنویسه و برای formatter هم همون jsonl رو استفاده کنه.
اسم لاگ فایل رو گفتم pyhints.log بذاره (تبلیفات نداریم دیگه)
و اما ۲ خط بعدی؛ وقتی از log rotate حرف میزنیم باید براش ی محدودیت بذاریم اینجا من گفتم بر اساس سایز باشه maxBytes روی 10mb یعنی اینکه اگر حجم فایل pyhints.log به 10mb رسید اسم فایل رو عوض کن (معمولا ی عدد به آخرش اضافه می‌کنه مثلا pyhinst.log.1) و این فایل رو کنار بذار و یک فایل جدید شروع کن دوباره به اسم pyhints.log.

اما خب شاید بگید چقدر از این فایل‌های 10mb درست می‌کنه ؟
یک کانفیگ اشتباه اینجا می‌تونه هارد سرور رو به راحتی پر کنه (این اتفاق هم میوفته)
پس توی خط بعدی بهش backupCount میدم؛ و اینجا بهش گفتم 10 تا ازون فایل‌های 10mb رو می‌تونی نهایتا نگهداری کنی؛ سوال: بعد از ۱۰ تا چی میشه ؟
هیچی قدیمی ترین فایل لاگ حذف میشه تا لاگ جدید نوشته بشه؛ یعنی توی این مثال وقتی pyhinst.log.10 ساخته شد دفعه بعدی که قرار باشه فایل نوشته بشه pyhints.log.1 حذف میشه و بار بعدی pyhints.log.2 و این چرخه تا لازم باشه تکرار میشه.
در نهایت هم encoding: utf8 خیلی‌ها میگن من حساس هستم و نیاز نیست و ... حق هم میدم بهشون.
ولی وقتی کدها ممکنه دست افراد و تیم بین‌المللی و چندزبانی بیوفته شخصا ترجیخ میدم دیفالت رو بذارم؛ اینجوری مثلا اگر دست یک شرکت چینی هم بدم کدهام رو اون‌ها می‌دونند درصورت نیاز کجای کد رو باید تغییر بدهند و utf16 بذارند و ...
پس این یعنی دردسر کمتر
و چه بهتر که وجود داشته باشه این دیفالت.