https://github.com/freedomofdevelopers/fod


درباب صحبت‌هایی که داخل گروه و کامنت شد،
این مورد رو جایگزین شِکن کنید.

قطعاً رستگار می‌شید

متأسفانه بعد از اتفاقات اخیری که توی کشور افتاد، وضعیت برنامه‌نویس‌ها و بطور کلی حوزه IT به شدت خراب شد.

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

اینکه بعضی دوستان می‌پرسند بمونیم یا بریم :
قطعاً به رفتن فکر کنید، موندن جز پشیمانی دستاوردی نداره (ماها موندیم)

پروژه شکن هم همونطور که قبلاً درباره‌اش صحبت کردم ،
DNS leakage
های بسیاری این اواخر داره و چون از شما میخواد روی کل ترافیک سیستم تنظیم کنید

امنیت کمتری داره نسبت به FOD.


بهشت اونجایی هست که آدما حق انتخاب داشته باشند حتی به غلط 👌

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

#Quick

PyScript

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

واقعا جالب هست و ارزش بررسی داره

PyScript GitHub

اینو میگم چون خودم برای تست ایده مجبور به یادگیری React شدم.

ازین مدل کد توی سورس کد پکیج‌ها زیاد دیدید همون استاندارد
EAFP
امروز یکی از نیروهای junior که باهاشون کار می‌کنم روی یکی از کدها به اروری میخورد و کار پیش نمی‌رفت.
ارور فریمورک هم واقعا نامشخص نبود و چیزی ازش دستمون رو نمی‌گرفت (زمانی که tensorflow 0.7 اومده بود قشنگ یادم هست ازین چالش‌ها زیاد داشتیم)

توی سورس اگر کدهارو بخونید یک ساختاری شبیه عکس وجود داره که باعث میشه در نهایت ارور خاص فریمورک برگرده؛ البته با یک تغییر کوچیک توی خط 10 :
raise CustomException('Finally we raise our custom error in framework.') from None

همین from None باعث میشه exception های قبلی چاپ نشه.

پاک کردن همین ۲ کلمه باعث شد توی ۵ دقیقه مشکل حل بشه‌.

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

مثال بالا در صورت وجود
from None

از Bard گوگل خواستم برام کد review انجام بده روی این کد decorator بالا

نه تنها جزئیاتش درست و خوبه
مزیتش اینه که دسترسی بهش رایگان هست، مسخره بازی chatGpt رو نداره
و فقط کافیه ip ایران نداشته باشید


کاملاً هم رایگان هست

کانفیگ logging برای من همیشه اذیت کننده هست.
بخش عمده‌ای از تسک‌های من مربوط میشه به
Deep learning, ML engineering

اما وجه دیگه کارم backend هست و software engineer برای همین خیلی کم پیش میاد نیاز داشته باشم ی لاگر با جزئیات بنویسم

از طرفی هم ۹۰٪ کدهایی که از بچه‌های بکند تحویل میگیرم ی logging نوشته شده که حافظه زیادی قرار هست بگیره (بخصوص روی سرور تست دارم صحبت میکنم که حجم لاگ بالا میره)

این کد رو قبلا برای Django نوشتم ؛ توضیح دادم تقریبا چند هفته بعد از شروع یادگیری یکی از بدترین پروژه‌های شرکت رو دست گذاشتم روش و شروع کردم به بازنویسی این لاگر رو برای اون نوشتم

هر لاگ فایل تا ۱۰ مگ حجم می‌تونه اشغال کنه و بعد از اون فایل ذخیره میشه به اسم backup تا ۱۰ تا ورژن ازین بکاپ‌ها نگه میدارم فقط و روی نسخه ۱۱

log rotate 

میخوره و قدیمی‌ترین فایل حذف میشه

البته این خیلی ساده‌اس ولی خب از اون کیلویی اضافه کردن logging فایل قطعا بهتره

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

@PyHints

اینم فایل سورس (حتما بخونید و درک کنید اول)

چندتا توضیح بدم راجب کد بالا و مسائل دیگه :

۱- کد بالا ربطی به django نداره، هرچند توی یک خط من برای مسیر فایل از django استفاده کردم. Logging مربوط به core python هست.

۲- بیش از ۳۰ نفر سوالاتشون راجب همین موضوع بود، تماماً هم مشترک (دوستان گروه برای همین منظور ساخته شده و بخش کامنت) ازین به بعد این سوالات رو فقط توی گروه بپرسید.

۳- توی پیام‌ها ویس ندید، مخصوصاً قبل از هماهنگ کردن ۹۹.۹٪ اصلا پیام رو باز نمی‌کنم اگر اینطور باش

۴- احوال پرسی و خبر پرسیدن رو نمی‌فهمم، بعد حالا اگر پرسیدید چرا منتظر جواب نمی‌مونید ؟
بجای خوب هستی و چه خبر، همون سلام کفایت می‌کنه و یا اگر عادت کردید برای غریبه از
امیدوارم سلامت باشید استفاده کنید بخدا قشنگتر هم هست

۵- قبل از سوال پرسیدن نیازی به تاریخچه نویسی نداره، کی بودید و چیکار کردید و چرا به من ربطی نداره واقعاً و اگر برای راهنمایی لازم باشه قطعاً خودم می‌پرسم از شما (بعضی‌ها ۲۰ تا پیام میذارند آخر سوال از یکی از پست‌های کانال می‌پرسند)

۶- نهایتاً، خواهش می‌کنم
خواهش می‌کنم
اصلی ترین رفتار برنامه‌نویسی رو رعایت کنید

پیام‌ها رو مختصر بنویسید همه‌ی موارد رو داخل یک پیام ارسال کنید بریده بریده پیام دادن اسپم حساب می‌شه

بدتر از بریده بریده پیام دادن ۷-۸ تا پیام فرستادن و در نهایت گفتن این هست که بگید، می‌تونم سوال بپرسم ؟!

بجای اسپم کردن، اصل سوال رو بپرسید لطفاً این خیلی خیلی مهم هست.


دوستانی که این موارد رو رعایت نمی‌کنند، حداقلش اینه که اجازه نمی‌دهند من وقت داشته باشم به باقی دوستان هم کمک کنم.

مرسی از همگی دوستانی که رعایت می‌کنند یا خواهند کرد 🌹

ازینجا تا همه‌جا حق 😂😂😂

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

برای همین توی ایران تا دلتون بخواد ریفکتور می‌بینیم (خیلی موارد البته بخاطر شیت کد بودن هست) ؛ ریفکتورهایی که فقط استانداردها رو تغییر دادند و وقتی کد رو مقایسه می‌کنید لزومی نمی‌بینید برای وقتی که گذاشته شده

برای این موضوع ما ۳ هفته وقت رو از دست دادیم روی یک پروژه (مربوط به ۳ ماه قبل هست) و خیلی دوست داشتم راجبش بنویسم چون دقیقا بعد از این موضوع توی تیم خودم روشی که خودم برای ریفکتور کردن دنبال می‌کنم رو ارائه دادم

نکته : اگر دارید system design رو تغییر میدید دیگه اسمش refactor نمی‌شه و این تکنیک جواب نمیده
اما اگر بعنوان مثال کدی رو روی پروداکشن دارید که داره کار می‌کنه و system design مناسبی داره و فقط کدها بد پیاده سازی شده و پرفورمنس خوبی نداره اونوقت به ریفکتور نیاز دارید و تکنیکی که میگم :

شخصا از تکنیکی استفاده می‌کنم که توی تیم بهش میگیم
3 step refactor
وقتی بیزینس درخواست فیچر جدیدی میده که اصن معلوم نیست موندگار هست یا رفتنی یا ... و فعلا فقط روی سرور تست قرار هست بالا بیاد
step 1:
do it as fast as possible (even shit code is ok)
توی سریعترین زمان ممکن اون رو توسعه میدیم حتی اگر shit code باشه (شیت کد رو هم توی تیم براش سقف گذاشتیم)

برای همین خیلی از فیچرها و اید‌ه‌های اولیه در ۵-۳۰ دقیقه پیاده‌سازی می‌شه
Fail fast

اما اگر کدی که قبلا زده شده رو داریم می‌بینم چون بیزینس توی یک بخشی تغییر خواسته یا سرعت بالاتر خواسته و ما توی بررسی به یک کد dependent هم برخورد کردیم
step 1 (not new feature):
Tag it as first seen ( CHECKED: )

با یک کلید مشترک (کل تیم سرش اجماع کردند) بصورت کامنت تگ میزنید مثلا توی تیم من کلید CHECKED: هست.
نکته این کلیدهارو به ابزارهای highlight توی IDE اضافه می‌کنید که سریعتر و راحت تر دیده بشه

اگر خود شما یا دولوپر دیگری توی تیم مجددا این کد رو ببینه اولین کاری که می‌کنه تبدیل تگ هست
step 2 (see it again) :
Tag it with ( Attention: )

اگر مجدد برای بار سوم اون تابع یا کلاس یا ... رو دیدید باید refactor بزنید رو سرش
step 3 ( 3rd time) :
PROBLEM: first priority is to refactor the code

توی این لحظه اولویت اصلی شما ریفکتور کردن تایع هست (هیچ چیزی مهمتر از این نیست)

البته شرایط خاص و ۱٪ هم داریم که در اون مواقع فقط tag میزنیم بدون ریفکتور
PROBLEM:

هر کدوم از اعضای تیم وقتی کدی رو pull - fetch میکنه اولین کاری که می‌کنه اینه که دنبال PROBLEM: باید بگرده و مشکلش رو برطرف کنه.
بعد می‌تونه به کار خودش ادامه بده.


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

ریفکتور کردن کل پروژه با تعریفی که از ریفکتور گفتم توی اکثر مواقع احمقانه بنظر میرسه باقی موارد هم نشون میده شما تخصص کار و درک کدهای دیگران رو ندارید متاسفانه.

@PyHints

پ.ن : وقتی یک نیرو تسک برای انجام دادن نداشته باشه بجای منتظر موندن تگ‌ها رو توی کد بر اساس اهمیت refactor سرچ میکنه و شروع به refactor کردن

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

توی چندماه گذشته که خیلی درگیر مارکت ایران شدم، متوجه شدم ما توی ایران از هر ۱۰۰۰ برنامه‌نویس ۹۹۹ تا فیلسوف داریم، یعنی خودمون اینطوری تربیت کردیم

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

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

خلاصه خودمون مقصریم همه‌ی این رفتارها
باعث میشه نیروهای نسل بعدی (جونیور و ...) بجای رفتار برنامه‌نویسی، مثل فیلسوف عمل کنه

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

کدوم رفتار :
Fail Fast
محیط تست و develop رو برای همین گذاشتند برای اینکه وقتی یک ایده میاد سریع کد بزنید و توی ۲ روز اثبات کنید که خوب هست یا نه

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

اینجوری می‌شه که چون بین فلاسفه اختلاف میوفته تستی که باید ۲ روزه انجام می‌شد و مطمئن می‌شدیم موضوع کار می‌کنه یا نه

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


توسعه استارتاپ و ایده برنامه‌نویسی تو ایران با این وضعیت صبر ایوب می‌خواد و عمر نوح.

برای همه‌ی 1.4k عضو کانال می‌نویسم:

ماها برنامه‌نویس هستیم نه فلاسفه، ما می‌تونیم ایده رو کد بزنیم و fail بشیم (محیط تست و توسعه برای همین هست) ما فیلسوف نیستیم که راجب مفاهیم انتزاعی فقط صحبت کنیم و چیزی جز همین بحث کردن در دست نداشته باشیم
بذارید fail fast رو برای ایران بومی سازی کنم :

Fail Fast, As Soon As Possible


@PyHints

جواب بر اساس تجربه شخصی خودم هست

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

خیلی از اعضا پرسیدند راجبش، قرار داد ۳ ماهه، موقت یا کارآموزی یا تست (هرجا یک چیزی صداش می‌کنند)

نمی‌دونم چرا ولی خیلی از دوستان نگران و ناراحت می‌شوند وقتی صحبت قرارداد موقت میشه
توی پیام‌هایی که برای من اومده بیش از ۶۰٪ حتی ترس دارند (مخصوصاً وقتی بیزینس متفاوت هست) بعضی‌ها حتی تست نکرده از ترس می‌خوان استعفا بدهند.

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

خواستم بگم یک موضوع طبیعی هست، فقط نباید بترسید برای رشد کردن و برای پیدا کردن اون موقعیتی که بهش علاقه دارید :

Seek discomfort

شاید ۱۰ تا بیزینس رو اصلا بهش علاقه نداشته باشید، قطعا اونجاها با چنگ و دندون هم که بمونید بازم پیشرفت نخواهید داشت دنبال تیم و بیزینسی باشید که سر شوق بیارتتون ولی از تست کردن نترسید

در نهایت بگم که من با هیچ شرکتی و هیچ آدمی قرارداد بلندمدت نمی‌بندم

قبل از این : حتماً باید ۳ ماهه - ۶ ماهه - ۱ ساله باشه و تحت هر شرایطی برای قراداد ۱ ساله حق دارم با اعلام بین ۲ هفته تا ۱ ماه زودتر از کار خارج بشم.

توی ۳ ماه گذشته : حتماً با قرارداد پاره‌وقت شروع می‌کنم و نهایتاً ۳ ماهه (حتی با بهترین دوستانم)
توی این ۳ ماه با ۱ تیم خداحافظی کردم و توی ۲ هفته گذشته تصمیم گرفتم با تیم دیگری هم خدافظی کنم.

شاید اگر برگردیم به ۱۰ سال قبل، منم همین نگرانی رو داشتم که وای قرارداد موقت و ....
ولی ۵ سال گذشته متوجه شدم، اولویت قطعاً شخص خودم هستم نه هیچ شرکتی، حتی کنار بهترین دوستانم اگر توی همکاری حالم خوب نباشه اون کار بدردم نمی‌خوره 👌

خلاصه : اگر ازین قراردادها براتون اومد به این فکر کنید که توی این ۳ ماه می‌تونید بفهمید:
۱- مدیریت چطوری هست و البته برخورد با نیروها ؟! فیک هست یا واقعی ؟!
۲- تعهدات شرکت چطور هست ؟! رفتار نیروها ؟!
۳- پرداخت‌ها چطوری هستند ؟ و ....

برای اون دوستانی که همون ابتدا استعفا می‌دهند هم یک توصیه فقط دارم :

بدون جنگیدن، شکست رو قبول نکن
شاید حریفت فقط بلوف می‌زنه، اونم تو جنگی که تهش مرگ نیست 😉

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

برای مثال توی کدهای قبلی می‌تونستم از
__qualname__

استفاده کنم تا بتونم خیلی راحت تر توی یک اسکریپت چندصد خط کد تابع مدنظرم رو پیدا کنم یا اگر یک اسم چندین بار استفاده شده بود گیج نشم؛ که خب به هردلیلی اینکار رو نکرده بودم متاسفانه

پیشنهاد می‌دم شما هم همینکار رو بکنید هربار فرصت دارید؛ دوباره پیاده‌سازی کنید و حتی گوگل کنید ولی سراغ کپی کردن از پروژه قبلی نرید.

__qualname__

رو هم جایگزین

__name__

کنید

@PyHints

تغییرات جالبی توی این ۲ روز داره اتفاق میوفته :

حدودا از ۱-۲ ماه قبل حالت
safe search
برای همه ایرانی ها فعال شد؛ google, duckduckgo , ... و خب تنظیماتش هم قابل غیرفعال سازی نبود

صحبتم این نیست ولی راهکارش :
sudo nmtui
Edit a connection
<select your network interface>
IPv4 Configuration section —> select show
DNS Server —-> select Add:
4.2.2.4
8.8.4.4
8.8.8.8
یکی ازینا یا هر ۳ رو انتخاب کنید
Select:
Ignore automatically obtained DNS parameters

بعد OK, میزنید و Back
Activate a connection
رو وارد میشید اون interface ایی که تنظیم کرده بودید رو یکبار غیر فعال و مجدد فعال می‌کنید
دیگه این اتفاق براتون نمیوفته توی آندروید و iOS و ... هم این تنظیمات هست.

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

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

روی سرویس‌ دهنده‌های دیگه اینکار رو کردم (سرورهای خودم) دیدم اون‌ها هم همینطور شده

بنظرتون اوضاع داره بدتر هم می‌شه ؟

با این وضعیت باید با رفقا هماهنگ کنم از starlink ایی که دارند استفاده کنیم پروژه‌هامون رو تحویل بدیم.
چون روی یکی از سرورها گیت‌هاب رو هم ندارم.


پ.ن :
فکر کن یکی بیاد بگه push میزنم پروژه‌ات رو
هر push میشه ۲۰۰۰ تومن ؛ هر pull پروژه خودت باشه ۱۰۰۰ تومن پروژه سنگین باشه ۵۰۰۰ تومن
هر pull request بین ۲۰۰۰ تا ۱۰.۰۰۰ تومن میوفته
و برای fetch and merge هم ۵۰۰۰ تا ۲۰.۰۰۰ تومن
اگر merge با conflict باشه ۵۰.۰۰۰ تومن میشه


لطفاً اگر این اتفاق برای شما هم افتاده اطلاع بدید.

اگر monitoring هم اضافه کنید
می‌بینید خیلی از سرویس دهنده‌های داخلی برای IP غیر ایران از ساعت ۱ شب به بعد از کار میوفته، اگر اطلاع بدید به پشتیبانی راه می‌اندازند مجدداً (و دوباره چند شب بعد, این اتفاق دائم در حال تکرار هست)
اگر نه حداقل چند روزی قطع خواهید بود.

توی عکس Downtime سرور ما برای کاربرهای خارجی از ۳ دقیقه شروع شد
تا رسید به ۳۰ دقیقه (ما هرشب اطلاع میدادیم)

ولی توی چندروز اخیر بالای چند ساعت هست که رکوردش توی عکس بالاس، برای از دست ندادن مشتری (استارتاپ همه‌ی درآمدش از ارائه سرویس خوب به مشتری هست) مجبوریم بریم روی سرورهای خارجی و سرویس دهنده‌های cloud داخلی رو بیخیال بشیم؛

مخصوصاً اینکه همشون میگن مشکل از درخواست‌های وزارت ارتباطات هست.
برای همین هم هرکاری کنیم هیچ خسارتی نمی‌تونیم بگیریم.

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

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

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

نکنید اینکارو، 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