Python Hints

#یادم_باشه حتماً یادم باشه نوشتن Log filter کاستوم رو یاد بدم، شرکت با یکی از شرکت‌های خدمات دهنده اروپایی قرارداد بسته و برای تست قرار شد، ۱ هفته یک کپی از دیتاهاشون رو بفرستند سمت log server ما. شاید باورتون نشه، ولی تمامی شماره‌های مشتری‌ها بدون اینکه حتی بخشی از شماره‌ها مخفی بشه بصورت کامل داخل Json log ها هست.

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

RotatingFileHandler, QueueHandler

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

این روش log نوشتن برای پروژه کوچک خوبه که تعداد request کمی هم داره، برای پروژه بزرگتر یا فریمورک و ابزارهای دیگه اصلا این روش توصیه نمی‌شه چون امروز با یکی از نیروها بحث شد، قرار شد یک سمپل بهشون بدم دیدم موضوع مهمی هست مخصوصاً بعد از اینکه به این پست اشاره کردند گفتم بهتر توی کانال هم بصورت نوشتاری بذارم سری پست‌های این هفته در مورد logging خواهد بود.

این یکی واقعاً برام سوال هست، دوستان سنیور، چطور میشه به یک نیرو منبعی رو معرفی کرد برای Design Pattern چیزی که زیاد می‌بینم اینه که خیلی از بچه‌ها، مطالب مربوط به design pattern رو می‌‌دونند و تعاریف و مثال‌ هارو به خوبی از پسشون بر میان (هرچند عمرا نمی‌بینید من تو مصاحبه تعریف چیزی رو بپرسم) ولی وقتی به کدها نگاه می‌کنیم، تصمیمات اشتباه زیاد دیده میشه اکثراً هم بعد از یک میت ۱۰ دقیقه طرف متوجه مشکل می‌شه و حتی راه حل درست رو می‌گه شخصاً هنوز کتاب یا دوره آموزشی ندیدم که Design Pattern هارو به خوبی و با چندتا مثال کد توی دنیای واقعی نشون بده. نرید Gang of Four رو برای من بیارید که شرط می‌بندم یکبارم نخوندید 😑 من این مورد رو برای توسعه دهنده‌های پایتون می‌خوام و با مثال واقعی.

#موقت درخواست عضویت تو گروه بعضی مواقع اجازه تأیید نمیده، مجبورم dismiss کنم اگر تأیید نشد، دوباره درخواست بدید.

یک توضیح کوچک راجب یوتیوب بدم، چون خیلی سوال شد. قرار بر همکاری با یک video editor بود و خوب هم داشت پیش میرفت ایده ساخت انیمیشن بود، و بعد از تست دوتا مبحث دیدیم که بهترین کار همین هست چون به خوبی مطالب رو انتقال و نمایش میده حدوداً ۵ موضوع، ویدئو نزدیک به ۲۰ دقیقه آماده شده بود که متأسفانه ایشون تصمیم گرفت ویدئو‌ها رو به بنده نده و ایده رو خودش ادامه بده و شاید تدریس بکنه. هرچند حتی اگر اینکار رو بکنه هم من ناراحت نیستم چون هدفم آموزش بود. به هر حال، دلیل اینکه کانال یوتیوب چیزی آپلود نشده این بود ( پیدا کردن همکار، آموزش کار با انیمیشن، ریکورد و ارسال و تدوین و ....) بسیار زمان‌بر بود و وقتی هم که ایشون کار رو یاد گرفت تصمیم گرفت که به بنده نده و حتی اگر لازم باشه دوره رو به فروش بذاره. ایده انیمیشن رو ندارم دیگه (هر ویدئو تقریباً ۲ هفته کار برد)، اما سعی دارم از کد برای ساخت تصاویر استفاده کنم که مفاهیم راحت‌تر منتقل بشه و هر زمان خالی که داشته باشم روی این موضوع کار می‌کنم (یادگیری خودم و ساخت ویدئو)

#تجربه فریمورک برای یادگیری core python نیست، سورس کد خوندن برای بهتر شدن هست نه یادگیری. چندروز قبل منتظر بودم یکی از بچه‌ها بیاد ازش یک وسیله‌ای رو تحویل بگیرم، دیدم زود رسیدم گفتم بد نیست برم یکجا بشینم ی قهوه بخورم. نشسته بودم سفارشم آماده بشه (قهوه نخوردم، چون dark roast داشت فقط) دیدم توی فضایی جداگانه کنار من (مثل بخش vip) یکنفر درحال آموزش دادن generator, yield, yield from هست، البته برای دیپ‌ لرنینگ و از روی فریمورک، متوجه شدم خیلی داشت اشتباه توضیح می‌داد. بعد از چند دقیقه که حواسم به کلاس اونها بود و مدرس حواسش به من، کلاس‌ ۵ دقیقه استراحت داد و متوجه شدم از اون ۱۲-۱۵ نفر ۳-۴ نفر عضو همین کانال هستند و مدرس و باقی اعضا همه رفیق هستند که دارند تلاش می‌کنند باهم یاد بگیرند. خداییش خیلی خیلی لذت بردم (کامیونیتی اینجوری لذت بخش هست) و توی این بحث و اینکه چطوری data loading, batching, ... توی فریمورک‌های هوش مصنوعی کار‌ می‌کنه مونده بودند و اشتباه این بود که بجای درک مطالب اصلی و عملکردشون سعی داشتند از framework این موضوع رو یاد بگیرند. چندتاشون سوال پرسیدند و براشون توضیح دادم، بعد دعوت کردن این مبحث رو توی کلاس آموزش بدم. منم که منتظر تماس بودم، شروع کردم با پایتون کد زدن و آموزش دادن و تأکید کردم این چیزا رو نباید با فریمورک یادگرفت هدف هرچی که باشه ولی واقعاً دیدن همچین کامیونیتی‌هایی لذت بسیار زیادی داره، یادگیری رایگان و دردسترس برای همه.

#Quick نوشتن list اطراف هر تابع باید دوبار بهش فکر کنید. اگر اون تابع یک generator باشه شما دارید بدترین کار ممکن رو می‌کنید. این مورد رو بین بچه‌های دیتاساینس و هوش خیلی زیاد می‌بینم و بین بچه‌های بکند هم وقتی دارند روی CSV, Json و یا Json-line کار می‌کنند. موضوع فقط مصرف زیاد رم نیست؛ موضوع سرعت هم هست اگر قرار به تمیزکاری و پردازش هر نمونه دپتا یا خط به خط هست لطفا از generator ها به درستی استفاده کنید مشکل دارن با ما؛ ما اینجا زحمت می‌کشیم generator می‌نویسیم بعد اینا سریع می‌ندازنش توی list تصویر ی نمونه خیلی ساده برای مثال هست (زمان اجرا کامنت شده)

روی این مورد از من راهکار خواستن (جلوتر مثال میزنم برای توضیح) همین اول کار بگم یک فرمول ثابت برای همه وجود نداره هرکسی گفت وجود داره کلاش هست .اگر فرمولش ثابت بود؛ برای همه بچه مدرسه‌ای ها و دانشجو‌ها استفاده میکردن که همه بتونند به درستی از تمام ظرفیت هوش و استعدادشون استفاده کنند. گفتند مشکل رو نشون دادن بدون راه‌حل فایده نداره. من خودم گفتم؛ چندسال مسئله خودم این بود که اصلا نمی‌دونستم نحوه خوندم اشتباه هست؛ آدم وقتی به اشتباه پی‌میبره تازه از اونجا دنبال راهکار میگرده کدوم یک از شما تو کدی که باگ و مشکل نداره؛ دنبال تغییر الگوریتم هستید ؟ پس پیدا کردن مشکل خودش ۷۰-۸۰٪ رسیدن به راه‌حل هست. درنهایت من با این مثال توضیج دادم؛ فکر کردم شاید مفید باشه هرچند یک جلسه لایو ویدئویی می‌تونست بهتر باشه : مثلا: فرض کن داکیومنت FastAPI رو داری میخونی؛ نمیری بشینی توضیح نحوه نوشته شدن generator رو بخونی؛ موارد مهم رو میخونی مثل get, post, route, authentication , ... یعد میای می‌بینی نوشته Async و تو میدونی لازم داری توی تمام پروژه‌هات مهم هست چیکار می‌کنی از روی دامکیومنت Fastapi میخونی ؟ قطعا نه؛ میری یک کتاب یا یک دوره براش پیدا میکنی که هدفش فقط همین باشه حالا فرض کن کتاب Async رو میخوای بخونی؛ توی ۳ فصل اول هم مقدمات پایتون هست میشینی از اول بخونی ؟ نه فقط نگاه به سرفصل میکنی و اگر همرو میشناختی حذف میکنی و از فصل ۴ شروع میکنی یک مثال دیگه کتاب fluent هست؛ این کتاب و کتابهای مشابه هر فصل یک هدفی داره شاید داخل یک فصل اومده مثلا فریمورک django رو مثال زده اینجا بر خلاف مثال قبلی Async , FastAPI شما نباید بری django رو بخونی اول به هدف فصل نگاه میکنی مثلا mixin (multiple inheritance) هست و بعد سعی میکنی همین رو درک کنی حالا اگر نویسنده کتاب زحمت کشیده ی مثال هم زده و شما بلد نیستی نباید برات مهم باشه چون اون مثال میشه حاشیه برای شما؛ چون تو اصلا بکند دولوپر نیستی.

#تعیین_سطح بعد از سری پست‌هایی که راجب دستمزد بود : Link مهمترین سوال اکثر دوستان نحوه تعیین سطح بود، از آخر شروع کنم و راحت‌ترین روش، اپلای کردن برای شغل سطح بالاتر هست اگر ۱۰ تا مصاحبه رفتید و بخاطر عدم دانش کافی رد شدید. یعنی اون سطح رو ندارید اما جزئی‌تر بخواب بگم : ۱- میزان دانش مثلاً برای پایتون، آیا می‌دونید mro, hash چی هستند و کجا استفاده میشه یا مثلاً sequence, iterator, iterable چی هست، yield, yield from یا multi process, multi thread چه تفاوتی دارند ؟ یا سوالات meta programmig، design principles ۲- غیر از زبان برنامه‌نویسی آیا اطلاعات پایه‌ای مهندسی کامپیوتر رو بلدید ؟ Data Structure, Algorithm, System design ۳- توانایی آنالیز و حل مسئله چطور هست ؟ این بخش همون مباحث leet code هست، اما به شرطی که بتونید نحوه حل مسئله رو بلند بلند توضیح بدید. تعیین سطح یک جا بدرد می‌خوره اونم مصاحبه هست، و چیزی که توی مغز شما می‌گذره‌ رو مصاحبه کننده نمی‌دونه پس باید بتونید همزمان با فکر کردن توضیح هم بدید. ۴- نحوه برخورد با مشکلات، بهت بگن سنیور یا هرچیزی اینجا جایگاهی هست که خودت رو نشون میدی قبلاً هم گفتم، وقتی درخواست یک فیچر جدید به کاری که برای خودت پلن کرده بودی اضافه میشه و غیر منطقی در برابر پیاده‌سازی مقاومت می‌کنی. تو سنیور نیستی، سنیور برای هر حرفی که میزنه دلیل منطقی داره (قرار نیست برای جونیور توضیح بده و وظیفه‌ام نداره) اما سوادش اونقدری هست که توی جلسه فیچر جلوی فیچر بدردنخور ایستادگی‌ کنه و یا حتی راهکار جایگزین ارائه بده. ۵- نیروی سنیور توانایی مدیریت نیروهای سطح پایین‌تر رو داره، می‌تونه توی پروژه‌ها، کدها و تصمیمات کمک کنه و مسیر درست رو بهشون نشون بده لیدر و منتور خوب بودن جزو خصیصه‌های نیروی سنیور هست ۶- موارد دیگری هم هست، مثل : سال‌های تجربه (شاید نه فقط از نظر فنی بلکه از نظر کار تیمی) نحوه برخورد با مشکلات داخل تیمی (مشکلات غیر فنی) میزان رشد (سنیور، هیچوقت منتظر نمی‌مونه ازش چیزی بخوان تا پیشرفت کنه و هیچوقت از یادگیری دست بر نمیداره) میزان پیچیدگی پروژه‌ای که روش کار می‌کنید و ... هر کدوم از موارد بالا رو می‌تونید به ترتیب از زیاد به کم بهش امتیاز بدید، خودتون متوجه حدود سطح خواهید شد. اما هیچکدوم از موارد بالا، باینری نیست توی همه موارد من گفتم سنیور ولی اگر شما مثلاً توی همون مثال اول چند مورد رو بلدی و چندتا رو نه، امتیاز کمتر از سنیور میگیری (مثلاً میدیور) در نهایت بازم میگیم، برای من بهترین تکنیک مصاحبه دادن هست اما اگر نمی‌تونید مصاحبه بدید، از Mock interview استفاده کنید (نهایت اینه که ۲ ساعت دستمزد پرداخت کنید). فقط تورو خدا نرید هر آدم رندمی که پیدا کردید باهاش مصاحبه کنید (حداقل کمی تجربه مصاحبه گرفتن داشته باشه) یا اینکه روی اون موضوع مسلط باشه منظورم رو با مثال بگم : فرض کنیم من یک دوستی دارم، مدرس دوره System Design ولی تجربه مصاحبه کردن نداره، من پیش ایشون نمیرم بگم بیا من رو تعیین سطح کن ببین استخدام میشم یا خیر چون احتمال زیاد ایشون بایاس هست به سمت تخصص خودش. اما می‌تونم از ایشون خواهش کنم من رو برای مبحث System Design یک مصاحبه تعیین سطح کنه، توی همچین Mock Interview قطعاً وقت هیچکدوم سر سوالات حاشیه‌ای نخواهد رفت و فقط ۲-۳ مورد. تمرین system design خواهیم داشت و اگر من seniority رو از ایشون بگیرم، خیالم روی این مبحث مصاحبه بسیار راحت خواهد بود. خلاصه که : توی مواردی که گفتم به خودتون امتیاز بدید، از مصاحبه دادن نترسید، اگر برای شرکت خاصی دارید آما می‌شید از mock interview غافل نشید، همونطور که گفتم برای مصاحبه آزمایشی با آدم درست هزینه و دستمزد پرداخت کنید، اما با آدم غلط مصاحبه نکنید. هم اعتماد به نفس شمارو خراب ، هم وقت شمارو تلف می‌کنه فرض کنید توی مصاحبه به شما توی راهنمایی اشتباه بگه که باید سطح advance سوالات leet code رو حل کنید. در حالی که ممکن دلیل رد شدن شما توی مصاحبه‌های سطح سنیور، عدم توضیح راه‌حل یا عدم توانایی مدیریت تنش و مشکلات و ... باشه.

#تجربه دوره کتابخوانی خودمون کتاب خوانی با چندتا از همکارای شرکت مقاله خوانی و ... باعث شد یک چیزی رو مطمئن بشم؛ ۹۸٪ کتاب خواندن رو بلد نیستیم البته حق هم داریم، دانشگاه و مدرسه و ... باعث و بانی این موضوع بوده و البته اینکه هیچ کس بهمون یاد نداد یا بهمون نگفت که داریم اشتباه می‌خونیم. شخصاً این مشکل رو داشتم. برای مثال: اول هفته با یکی از همکاران شرکت شروع به خواندن یک کتاب کردیم (بخش تحقیقات) من دیروز کتاب رو تموم کردم و شروع کردم به کد زدن (با اینکه من جاهای دیگه هم کار می‌کنم) وقتی pull request زدم و درخواست peer review دادم، بهم گفت که تازه ۱٫۳ کتاب رو خوانده. خیلی ساده ببینید که آیا شما کتاب خواندن رو بلد هستید یا خیر، اگر مدل خواندن شما برای شرایط زیر فرق می‌کنه میشه امیدوار بود : ۱- خواندن برای آزمون تئوری (مثلاً LPIC) ۲- خواندن برای آزمون عملی (مثلاً RHCSA) ۳- خواندن برای یادگیری نکته‌ای (fluent python) ۴- خواندن برای یادگیری دقیق ( fastapi documentation ) اگر توی همه این موارد فرمول خواندن شما یکسان هست، اگر موقع خواندن (حتی دیجیتال) ورق و قلم بغل دستت نداری متأسفانه باید بگم که شما کتاب خواندن درست رو بلد نیستید، و همین داره وقتتون رو می‌گیره یا شمارو خسته می‌کنه.

پست قبلی که گذاشتم راجب uv حقیقتا از اینجا متوجه پروژه شدم که تیم‌های Data Engineering, Backend, Test توافق کردند از ruff استفاده کنند، بخصوص که حالا دیگه vs-code extension هم براش وجود داره و خیلی راحت شده کار بچه‌ها گفتند ما هم بریم سراغش و منم دارم بررسی می‌کنم که نظراتم رو راجبش بدم، نسبت به تمام کانفیگ‌هایی که داریم. تا اینجا که خیلی خوب پیش رفته (از صبح).

ابزار جدیدی از astral اومده به اسم uv جاگزینی خواهد بود برای pip, poetry, ... البته درحال حاضر خیلی خام هست ولی بطور خیره کننده‌ای سرعت بالایی داره حتما یک سری بهش بزنید. uv: Python packaging in Rust

اضافه کنم که تصویر مربوط به محیط zellij هست یا دقت کردید ؟

3- Btop

بخش بالایی عکس که جزئیات cpu, mem, hard, network, gpu رو به خوبی نشون میده مربوط به ابزار مانیتورینگ btop هست که یک جایگزین فوق‌العاده و بسیار قوی برای top, htop محسوب می‌شه. اما گل سرسبد همه موارد بالا و هرچیز دیگری که می‌شناسید : 4- tldr تصویر گوشه پایین راست؛ اصلا نمی‌شه شما کاربر لینوکس باشید و از کامند استفاده کنید و نیازمند man نشده باشید. اونقدری که خوندن و استفاده درست از man page یکی از سرفصل‌های مهم آموزشی RedHat هست؛ اگر می‌گید چه ربطی داره ؟ باید بگم که tldr اومده که شمارو از خوندن man page خلاص کنه مخصوصا وقتی فقط ی مثال کوچیک و سریع + توضیح کوتاه لازم دارید. توی تصویر شما خروجی tldr dust رو می‌بینید. می‌دونم ربطی به پایتون نداشت؛ ولی چون خیلی کمک هست این ابزارها گفتم شاید بدرد کسی بخوره اینجاهم. امیدوارم مفید باشه 🌹 @PyHints

#لینوکس ۳ تا از ابزارهایی که بنظرم هرکسی باید روی سیستم داشته باشه یکی از همکارا توی میت پرسید؛ انقدر مفید بود که باقی بجه‌ها رو هم صدا زد. واقعا فکر نمی‌کردم کسی اینارو نداشته باشه برای همین گفتم اینجا هم به اشتراک بذارم:

1- zellij

اگر با tmux کار نکردید که قطعا عمرتون رو خیلی هدر دادید و اگر کارکردید و مثل من خیلی وقتا درگیر کانفیگ کردنش بودید؛ برید سراغ zellij خوبی این ابزار اینه که با Rust نوشته شده فوق‌العاده کم حجم و سبک هست کانفیگ شده و همه چیز رو داره همیشه هم منو راهنما جلوتون هست تعداد فیچرهاش بیش از حد زیاده. 2- dust فقط کافیه یکبار هاردتون پر شده باشه تا سردرد استفاده از du, df , ... رو چشیده باشید یعنی ادمین سرور ندیدم که رضایت داشته باشه. dust گوشه سمت چپ پایین؛ کار رو به قشنگی براتون در میاره نمایش درختی + حجم هر پوشه و ... با زبان Rust نوشته شده و برای ایندکس کردن هارد ۱۶ ترابایتی و پر از فایل من فقط به ۵ دقیقه وقت نیاز داشت ( این هارد چون دیتاست زیادی شامل متن - عکس و ... داخلش هست بسیار ایندکس کردنش سنگین هست خودم روی ۱ ساعت فکر میکردم انجام بشه)

سایت‌هایی که از ساعت ۱ ظهر  برای بنده و چندتا از دوستان بدون فیلترشکن دیگه باز نمی‌شه : meet.google.com github.com pypi.org pytorch.org

سایت‌هایی که از ساعت ۱ ظهر برای بنده و چندتا از دوستان بدون فیلترشکن دیگه باز نمی‌شه : meet.google.com github.com pypi.org