توی دوره‌های آموزشی و دانشگاه چیکار می‌کنند ؟!

چرا همه جوری صحبت می‌کنند که انگار همین یک دوره، همین یک کتاب یا ... برای کار و کل عمر کفایت می‌کنه ؟!

نکنید اینکارو، Junior های عزیز بعضی ازین برگذار کننده‌های دوره که فقط به فکر سود شخصی هستند شما مراقب باشید سمت این افراد نرید.

نه بخاطر پول، حتی نه بخاطر وقت که دقیقاً تو دنیای الان برنامه‌نویسی مثل طلا می‌مونه

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

پست‌های کانال سطح بالاتری از تازه‌کار داره، حتی ممکنه یک سنیور رو ببینید که این مطالب رو بلد نیست (اشکالی هم نداره تا حدودی، چون بهش نیازی نداشته شاید)

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

حتی بعد از اینکه شغل پیدا کردید، باید یاد بگیرید مصاحبه کنید
این حق شما هست که دنبال کار بهتر با مزایای بیشتر باشید حتی اگر ۱ ماه بعد کار بهتری رو پیدا کنید.

مصاحبه دادن و نترسیدن از رد شدن توی مصاحبه، اولین و مهمترین قدم برای پیشرفت و senior شدن هست

مهمتر اینکه :
همیشه بپرسید به چه دلیل رد شدید.

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

متاسفانه ازونجایی که همه چیز Notebook هست و این کدها فقط بین تیمی جابجا می‌شه و ۹۹٪ کارفرماها وقتی کارشون نزدیک لانچ شدن محصول هست سراغ اضافه کردن سیستم هوش مصنوعی میان کدهای تمیزی معمولا نمی‌بینید

مثلا من خیلی از کدها رو توی ۲-۳ روز زدم و تحویل دادم به بخش‌های دیگه با توضیحات و جلسه که بره روی محصول
چندسال پیش وقتی دنبال کار جدیدی بودم کدهای قدیمی‌تر (قبل از کار توی حوزه هوش مصنوعی) رو اتفاقی باز کردم همراه با یکی از دوستان که مصاحبه میگرفت ازم و بدون تعارف بهم گفت :
این کدها (کدهای قدیمی) سطح سنیور داره ولی این یکی (کدهایی که توی notebook زده بودم) انگار دادی ی بچه کد زده راستم می‌گفت؛ کار تو زمینه هوش مصنوعی و notebook من رو تنیل کرده بود نه فقط من کل تیمی رو هم که نگاه کردم همین بود

Don't Repeat Yourself (DRY) 

اصلا رعایت نمی‌شد؛ ۲ تا کلید رو همزمان فشار میدادی کل cell بالایی رو کپی میکرد توی cell جدید ۲ تا کلید دیگه میزدی هرچی train بود رو با valid عوض میکردی بعد همین رو دوباره تکرار میکردی و میزدی test در نهایتم بخش‌های دیگه از ما ۴ تا فایل تمیز میخواستند که بهشون خیلی شیک و مجلسی تحویل میدادیم دیگه

بعد این صحبت‌ها مطمئن بودم دیگه فعلا نمی‌تونم برم سراغ کارهای software engineering چون اصول کد نویسی تمیز و ... رو اصلا نمی‌تونستم رعایت کنم ولی اگر یک نفر می‌گفت من این کد رو ۷ روزه تحویل میدم من همون کد رو نهایتا ۴ ساعته تحویل میدادم (اما کثیف و بدون رعایت اصول)
برای همین بجای software engineering رفتم سراغ machine learning engineering حالا خودم باید اون ۴ تا فایل رو تحویل میگرفتم تمیز میکردم و کدهای تمیز و تست و ... براش می‌نوشتم
این موضوع خیلی بهم کمک کرد تا عادت‌های بد رو کنار بذارم؛ به کدهام ساختار بدم سعی کنم کامنت و ... بذارم یا حداقل اصول اصلی رو رعایت کنم (هنوزم کامنت گذاری و docstring برام سخت هست)


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

من واقعا و جدا الان دارم روزی ۱-۲ ساعت تمرین تمیز کد زدن می‌کنم؛ تا توی ناخودآگاهم بمونه این موضوع؛ علاوه بر اون دارم بسیار تمرین می‌کنم و برنامه‌ریزی می‌کنم با کارفرماهای عجول کار نکنم و اگر دارم کار می‌کنم خداحافظی کنم.

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

خلاصه که خیلی خیلی حواستون باشه؛ بخصوص دوستان سنیور.

پ.ن : اضافه کنم الان چندماهی هست ۲ تا از شغل‌هام بعنوان

software engineer 

هست ولی خب سختی زیادی کشیدم تا عادت‌های بد رو کنار بذارم و هنوزم درحال تمرین هستم؛ اینم به این معنی نیست که بگم برید کتاب clean code بخونید ( ی مدت ملت جوگیر شده بودند هرجا میرفتی دست یکی این کتاب بود؛ خلاصه بگم اصلا هم کتاب خوبی نیست قبلا مفصل راجبش توی چندتا لایو که دعوت بودم بحث کردم)

بنظرتون کدوم تابع سریعتر هست ؟
دلیلش رو هم می‌دونید ؟
کد رو بهبود دادم (چون مجبور شدم لوکال اجرا کنم) که رم سیستم پر نشه الکی

مرسی از دوستان که سریعا مشکل کد قبلی رو اشاره کردند 🌹

@PyHints

بگذریم ازین که اکثریت جوابی نمی‌دید.

ولی حقیقتش این مثال رو نزدم که همگی بگید تابع
total_sum
و برای دلیل هم بگید که :
چون sum توی Cpython پیاده سازی شده و بدون اینکه نیازی به ساخت Object های پایتونی داشته باشه می‌تونه عملیات ریاضی جمع زدن رو انجام بده و سربار چک کردن نوع Object و وجود متدهای مورد نیاز و object type و ... رو نداره (توجه کنید من روی ۳.۸ صحبت می‌کنم و نه ۳.۱۱ پس همه این موارد به نوعی صادق هست) تازه با C هم پیاده سازی می‌شه و سریعتر هست.

که خب خودش جواب خیلی جزئی و درستی هست (همین که بگید توی C اجرا میشه هم جواب درست رو دادید) و نشون میده درک بالایی از پایتون دارید.

من این مثال رو زدم تا شمارو با پکیج
dis
آشنا کنم راجب Profiling , همین dis قبلا صحبت کردم (توی کانال‌های دیگر) اما لازم بود اینجا هم صحبت کنم؛
Profiling
رو حقیقتش دنبال مثالی هستم که بتونم توی نهایتا ۴ تا پست توضیحش بدم (بگذریم ازش) اما dis یک مرحله بالاتر هست.

مثال بالا رو فعلا کامل فراموش کنید

توی کار وقتایی پیش میاد که خروجی یک روش از روش دیگری سریعتر هست درحالی که منطق هر ۲ تا تابع یکسان هست
توی این شرایط معمولا کاری که می‌کنند اینه که
ی timeit میزنند و اون تابع رو چند ده یا چندصد بار اجرا می‌کنند مطمئن بشوند بطور میانگین چطوری هست
profiling
انجام میدیم که مطمئن بشیم p value به اندازی هست که نگیم رندم هست این بهبود زمانی و ...

حالا بیاید فرض کنیم که بهبود واقعی هست ولی از نظر منطقی توی هر ۲ مورد یکسان هست توی این شرایط هیچ ابزاری نمی‌تونه کمک کنه به غیر از
dis

برگردیم به مثال قبل و توی پست بعدی ببینیم dis چیکار می‌کنه

@PyHints

اول از همه این خروجی dis هست برای ۲ تا تابع مثال قبلی که با
=======
از هم جدا شده؛ از تعداد operation مورد نیاز می‌شه فهمید که خب تابع دوم ینی sum چرا سریعتر هست برای اجرا هم اینطوری استفاده‌اش کنید
import dis
print(dis.dis(total_sum))

@PyHints

خوندن خود dis از اجرا کردنش مهمتره

اولین ستون از سمت چپ میگه که کدوم خط از کد باعث تولید byte code (ستون پنجم شده) بعنوان مثال توی کدهای من خط 13 سورس کد باعث تولید ۴ خط Byte code ایی که می‌بینید شد.
ستون دوم : احتمالا نمی‌بینید این مورد رو توی کد بالا هم نیست (مثالی تو ذهنم نبود که این مورد رو توضیح بدم) اما نشون دهنده اینه که کدوم byte code توی خط به خط اجرا شده

ستون سوم :

»

نشون دهنده JUMP هست ینی مثلا توی byte code مربوط به

FOR_ITER

قطعا یک JUMP داریم هربار که به انتهای for loop میرسیم باید برگردیم اولش و دستورات رو مجدد اجرا کنیم تا وقتی که شرط دیگه درست نباشه.

ستون ۴: آدرس دهی byte code هست ینی توی مثال بالا آدرس همون FOR_ITER ایی که مثال زدیم توی byte code

8

هست.

سوال مصاحبه‌‌ای که از من شد (برای

optimization tuning 

فک کنم RedHat و قبل از ادغام با IBM) البته سوال ساده‌ای بود ولی خب؛
دقت کنید فقط اعداد زوج هستند و هربار ۲ تا خونه حافظه جلو میره
دلیلش اینه که

byte code

توی نسخه فعلی و این ورژن پایتون 3.8

2 Byte 

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

ستون ۵ :
opname
اگر مصاحبه برای optimization خواستید شرکت کنید بهتره بطور کلی لیستش رو توی داکیومنت پایتون بخونید و اگر هم با
Assembly
کد زده باشید که می‌دونید داستان چی هست (دوستانی که امنیت کار می‌کنند و مهندسی معکوس حرفه‌ای هستند این مورد رو 😁)

ستون ۶ : آرگومان مورد استفاده چه موردی که شما نیاز داری چه مواردی که خود پایتون بهشون نیاز داره بازم برگریدم به بایت کد مربوط به FOR_LOOP دقت کنید؛ ستون ۶ نوشته 12 که آدرس byte code بعدی درصورت درست بودن شرط for loop هست چون internal هست به نوعی استثنا هست (البته حقیقت اینه که استثنا نیست ولی چون توضیح و تفسیرش از همین حد الان هم advance تر هست ترجیح میدیم فعلا بعنوان استثنا ببینیمش)

ستون ۷: اسم
human readable
اسم خوانا برای اینکه راحت بخونیم و بدونیم تغییرات روی کدوم متغییر تعریف شده توسط ما داره انجام‌ ‌می‌شه
ولی بازم به FOR_ITER توجه کنید؛ روبروش برای ستون هفتم نوشته
to 22

ینی وقتی شرط for loop درست نبود به این byte code منتقل بشه و ازینجا به بعد اجرا کنه کد رو و چون تو ستون اول نوشته ۹؛ می‌دونم که خط ۹ خارج از for loop من هست و دستور

return total

توی پایتون اجرا خواهد شد.

@PyHints

چندتا نکته راجب پست‌های بالا :

اگر این موارد رو بلد نبودید؛ بلد نیستید و یا حتی توضیحات بالا براتون سنگین هست :
۱- ممکنه من بد توضیح داده باشم (تایپش واقعا ۱۰ برابر توضیح رو سخت‌تر می‌کنه)
۲- یادتون نره سطح مباحث mid-level به بالا هست اونم mid-level واقعی نه ازینا که بعد از ۲ سال کار کردن سطح خودشون رو بالا میبرند.

این پست استثنایی هست و سطح

Upper Senior 

هست پس اصلا نگران نشید.

احتمالا بسیاری نیروی senior می‌بینید که حتی اگر اسم
dis module
رو شنیده باشند تفسیر کردنش رو بلد نیستند؛ بازم میگم چون نیازی نداشتند

اما الان با جزئیات خوبی می‌دونید که دفعه بعدی که برای کدهای پایتونی و توی محیط توسعه مورد علاقتون
debugger
رو اجرا می‌کنید چطور عمل می‌کنه و مقادیر متغییرها؛ byte code؛ خونه حافظه و ... همرو بهتون نشون میده بخش عمده‌ای از اطلاعاتش رو ازینجا بدست میاره

حالا علاوه بر اینها شاید درک کنید که چرا نوشتن از Profiler برام سخت هست (بیشترم بخاطر توضیح نحوه تفسیرش هست)

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

لطفاْ reaction رو فراموش نکنید؛ وقتی کم می‌شه من فقط سیگنال میگیرم که اون پست یا موضوع رو دوست نداشتید و نمی‌خواید راجب اون یا موضوعات مشابه بشنوید (جدی میگم) دلیل ادامه ندادن بعضی مباحث هم همین هست واقعا
روی تمامی پست ها reaction رو داشته باشیم لطفا


ارادتمند عباسی

@PyHints

مورد ۱، ۶، ۷

۸۰-۹۰٪ سوالاتی که دوستان بصورت پیام خصوصی برای من می‌فرستند

ازین به بعد جواب نخواهم داد
چون باعث میشه سوالات مهم رو نتونم پاسخ بدم 🌹

این پست استثنا هست :

توی مدتی که دارم django میخونم خیلی ایراد دیدم توی کدهای توسعه داده شده توسط دوستان
من خودمم اشتباه زیاد دارم؛ ولی خب در نظر بگیرید من سنیور django نیستم و تازه شروع کردم اما آشنایی بالایی که با
‏system design, software engineering

دارم باعث میشه خیلی از دوستان لطف کنند و من رو هم در زمره سنیورهای جنگو قرار بدند (هنوز سابقه ام به یکسال نرسیده)

یکی از معظلاتی که رو آپدیت پروژه شرکت داشتم؛ سرعت پایین کدهای تست بود و متاسفانه هیچکس هم نتونست کمکم کنه روی این موضوع

حالا به کتابی برخوردم که آرزو میکردم ۱ سال پیش پیداش کرده بودم یا حداقل یک
‏senior
بهم معرفی میکرد که بخونم.

برای اینکه کسی مثل من نشه و چون django developer بسیار داریم این پست و کتاب رو گذاشتم.

کتاب رو گذاشتم؛ چون خرید از ایران بسیار سخت بود.

Adam Johnson - Speedup your django tests

کتاب راحت ۱۰ ستاره هست؛ هم بخاطر اهمیت موضوع هم نوشتار و …

توی هفته گذشته به یک جمع‌بندی دیگه هم رسیدم

درصد جوگیری توی ایران خیلی بالاس،
Mojo
رو قطعاً دیدید دیگه ؟
اگر ندیدید خوش بحالتون

قبل ازین که جوگیر بشید، مثل ۱-۲ از همکارای مثلاً senior من توی جلسه بجای راهکار‌های
Optimization
راهکار بدید از mojo استفاده کنیم در نظر بگیرید:

۱- پروژه Typing توی پایتون که این روزا بسیار طرفدار داره توی دنیای پایتون :
وقتی اولین بار توسعه داده شد، ایده اصلی این بود که
Python static type
بشه، که خود شخص
Guido van Rossum
متقاعدشون می‌کنه بجای اینکار Typing رو‌ اضافه کنند.

۲- این اولین بار نیست که اینکار داره انجام می‌شه یا تلاش می‌شه انجام بشه ولی خب شاید بهترین هست

۳- کسانی که پشت این پروژه هستند یک پروژه خوب دیگه هم دارند که چون استاندارد‌های صنعت رو رعایت نکرده بود هیچوقت صنعتی نشد
FastAi

منم بیشتر فکر می‌کنم
Mojo
بدرد
Data science, ...
میخوره نه پروژه صنعتی و نه software engineering
البته همینم نه توصیه می‌کنم نه خودم الان سراغش میرم


ولی اگر دنبال ی چیز باحال میگردید که هم آینده داشته باشه هم وقت خالی شمارو پر کنه هم سرعت خوب بهتون تحویل بده

Rust
رو یاد بگیرید.

درنهایت : لطفاً جوگیر نشید، جو زده عمل نکنید 🌹❤️

پ.ن :
FastAi, FastApi
با هم فرق داره

وقتی از 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