ترجمه انگلیسی موسیقی (اگر موسیقی رو بدون درک متن گوش نمی‌دید)
It's Raining Tears
I love you1
You've left, I remain alone, I have so much sorrow
I pray to heaven, pray to hell that you come back
To you, I scream words of love, words of hate

I love you
Just yesterday, you were here, you were mine
I don't know where my life is going; time drags on
And I'm only a prisoner crying over his chains

It's raining tears in the evening wind
Drowning my sorrow and my desperation
It's raining tears and the time goes
And the gray night dead already
It's raining tears, I see you everywhere
Alone in the city, I go no matter where
My steps sounding like a heart that beats
It rains tears sometimes

I love you
You are everywhere; in the house that is [now] like you
In those objects that we chose together
And your scent still awaits in our room

I love you
You left one day as one leaves on a holiday
But the long road of absence seems quite long
Yet you are mine even in your silence

It's raining tears in the evening wind
Drowning my sorrow and my desperation
It's raining tears and times goes
And the gray night dead already
It's raining tears, I see you everywhere
Alone in the city, I go no matter where
My steps sounding like a heart that beats
It rains tears sometimes

It's raining tears in the evening wind
Drowning my sorrow and my desperation
It's raining tears and times goes
And the gray night dead already
It's raining tears, I see you everywhere
Alone in the city, I go no matter where
My steps sounding like a heart that beats
It rains tears sometimes

#Advance_optimization
سطح این مطلب
Senior
هست (حتی میشه گفت senior با تجربه بالا) پس اگر دفعه اول نگرفتید داستان چیه اشکالی نداره واقعا

مثال پایتون :
توی کار برای مقایسه اینکه کدوم نسخه از کد سریعتر هست ار پروفایلر استفاده می‌کنیم
شخصا بالاتر scalene رو معرفی کردم که حالا پروفایلر اولم شده بطور ساده
scalene mycode.py —cli

حالا فرض کنید کد شما از کدی که همکار یا نیروی با تجربه تر تحویل داده کندتر هست اما از لحاظ منطق واقعا کدها یکسان هست و نباید کد شما ضعیفتر عمل کنه (خیلی پیش میاد هم تو مسابقه هم توی کارهای بزرگ)
اینجور وقتا دیگه profiler کمکی نمی‌کنه

باید بریم سراغ چیزهای قشنگتر :
import dis

print(dis.dis(myfunc))

این ماژول و کد بهتون Bytecode ایی که سورس کد شما اینجا myfunc بهش تبدیل شده رو براتون بر میگردونه
و بعد از بررسی دقیق می‌تونید بفهمید چرا کدی که از لحاظ منطقی یکسان هست از نظر زمان اجرا کندتر یا سریعتر هست.

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

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

Youtube Link

ی مقدار از وقتایی خالی رو به Rust اختصاص دادم :
و توی آموزش‌های اولیه‌ای که دیدم بنظرم این مورد از
Microsoft Developer
خیلی خوب بود؛ هم ویدئو‌ها کوتاه هستند هم اینکه مقدمات رو میگه
(شاید شما اصلا از Rust خوشتون نیاد و بخواید Go رو دنبال کنید)
Youtube Link

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

پ.ن :
transformers.tokenizer
روی Rust نوشته شده یک پروژه برای پشتیبانی با pytorch هم اومده
google
هم در حال استخدام نیرو برای gcp , ml-department هست پس امکان استفاده برای کارهای ما هم کم کم درحال فراهم شدن هست.

روی پروژه ای که شرکت با Netflix همکاری می‌کرد کار من و تیمم این بود.

قبلاً نمی‌تونستم راجبش توضیح بدم اما الان میشه 😬

(این ویدئو ربطی به پروژه ما نداره)

این مقاله‌ای هست که دید خوبی به من و تیم راجب این task داد.
برای کسانی که پرسیدند.

arxiv link

ما هنوز درحال یادگیری هستیم
تعریف Decorator توی کار ما خیلی مرسوم نیست؛ حقیقتا خیلی هم بکار نمیاد مگر توی مواقع debug , ...
خیلی کم پیش میاد که decorator ایی رو بخوایم روی production استفاده کنیم.

الان داشتم یک task ایی رو انجام میدادم که بعد از refactor کردن کد دیدم یکی از class هام تبدیل شد به یک کلاس ساده با 1 دونه method.

بهترین راهکار اینه که اینو تبدیل به closure کنیم (decorator) که هزینه اضافی واسه سربار class ندیم؛ همینکار رو هم کردم اما توی مدل production باید بشه از تابع decorate شده help , ... اش رو گرفت ولی وقتی decorator میزنید همه چیز با تابع داخلی قراره replace بشه اول اومدم دستی موارد مهم رو درست کنم مثلا

wrapper.__name__ = fn.__name__

اما خیلی کار بیخودی بنظرم اومد با یک جستجو به یک decorator دیگه مخصوص همینکار رسیدم
from functools import wraps
و فقط کافی بود بهش بگم که metadata رو از تابع اصلی برداره و به تابع داخلی decorator اضافه کنه درنهایت ی همچین چیزی میشه :

from functools import wraps

def decorator(fn):

@wraps(fn)
def wrapper(*args, **kwargs):
print("wrapped")
res = fn(*args, **kwargs)
return res
return wrapper

#tips
کاری به باقی حوزه‌های توسعه پایتون نداریم اما اگر توی کار دیتاساینس و ... هستید و با دیتای tabular (دیتای شامل ستون و سطر) کار می‌کنید و البته بصورت تیمی خواهش می‌کنم ۲ مورد رو رعایت کنید :
1- namedtuple
از این مورد استفاده کنید بجای tuple , list , ... که مجبور نباشید توی داکیومنت و کد هر لحظه بنویسید که ستون‌های دیتابیس چی بوده و چطوری map میشه به هر عنصر tuple
عکس: توی خط دوم اصلا لازم نیست من بهتون بگم که چه دیتایی رو نگه میدارم یا هر عنصر چه معنی میده خودتون متوجه می‌شید

2- Unpacking
دسترسی به دیتا هم راحت تر هست بجای اینکه حفظ کنم کدوم عنصر چی بهم میداد اسمش رو صدا زدم :
apple.CLOSED

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

*_

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

این نمونه (شاید اصن درست نباشه فقط همینطوری ساختمش بچه‌های finance کار ببخشید) فقط ۸ تا ستون داره
خیلی وقتا tuple هایی داریم با بیش از ۵۰ تا ستون اگر با namedtuple عوضش کنید فقط کافیه namedtuple رو یکبار توی utility های پروژه تعریف کنید

خبر کوتاه ولی پر از درد :

تایید فروش اموال مازاد دولت ایران با مصونیت قضایی.

مشتری اول: چین
مشتری دوم: روسیه

واقعا هر لحظه وجود آخوند تو ایران ننگ چند هزار ساله هست.

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

#تجربه

اینها نظرات شخصی من بعد از چندین سال برنامه‌نویسی، پرسش از برنامه‌نویس‌های دیگه و ... هست (اما شما همرو بخون تجربیات شخصی)

برنامه‌نویس بشیم یا نشیم (برای نسل بعدی) !؟

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

بعد از من پرسید بنظر شما که چندین سال هست توی این کار مشغول هستی چطور میشه فهمید یک نفر برنامه‌نویس خوبی میشه در نهایت یا نه !؟

شاید تا این لحظه سخت‌ترین سوالی بود که ازم پرسیده شده ینی حاضر بودم transformer رو برای دختر ۹ سالش توضیح بدم ولی این سوال رو نمی‌پرسید
واقعاً جواب سختی داره (یا حداقل من هیچوقت بهش فکر نکردم)

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

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

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

اما اینکه دخترتون بخواد برنامه‌نویسی رو شغل خودش بدونه و خیلی موفق بشه بنظرم ۴ تا ویژگی رو باید داشته باشه :

۱- ذهن پرسشگر : هر چیزی رو بدون دانستن چرایی قبول نکنه

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

۳- پیگیر باشه (مخصوصاً برای یادگیری) : متاسفانه یا خوشبختانه برنامه‌نویسی نه تنها ته نداره بلکه هرروز دستاوردهای جدیدی داره
مثال : شاید تا زمانی که دختر ایشون به سن دانشگاهی برسه کامپیوترهای فعلی از رده خارج حساب بشن و کامپیوتر‌های کوانتومی وارد بازار حتی pc ها بشه (شخصا فکر می‌کنم خیلی دور نیست اون روز)

این مورد اولویت نیست شاید ولی خب خوبه بهش دقت کردن : (البته نه توی ۹ سالگی که بعد از ۱۵ سالگی شاید)

۴- آدم آرامش و صبر باشه.

بنظر من این ۴ تا از هر مورد دیگه‌ای مهمتر بود:

ولی تو نظر بچه‌های دیگه تا دلتون بخواد
Team work
شنیدم بنظرم انقدر مهم نیست، برنامه‌نویس‌های بزرگی توی گذشته و حال بودند و هستند که team work یا روابط اجتماعی رو به میزان عادی دارند (پس نمی‌تونه توی اولویت‌ها باشه)

شاید الان عالی نباشه ولی ممکنه باعث ایجاد جرقه ایده‌های خوب برای آینده بشه :

Geoff Hinton explains the Forward-Forward Algorithm

این دوره رو سروش عزیز تو گروه معرفی کردند

این چندروز یک نگاهی به سرفصل‌ها و نحوه تدریس کردم واقعا عالی بود بنظرم کل ریاضیات واجب برای هوش مصنوعی توی این دوره هست که می‌تونید با audit کردن توی هر ۳ تا درس این دوره رو رایگان ببینید

برای همه بچه‌های تازه‌کار حتما و ۱۰۰٪ باید دیده بشه (یا حتی اونایی که ریاضیات ضعیفی دارند)

اونایی هم که دوره دوست ندارند بگند ۳ تا کتابی که خودم خوندم قبل از وجود این دوره رو بهشون معرفی کنم 😅

Coursera Link

Dramatron

اینو برسونید به بچه‌های تئاتری که سر نمره نمایشنامه نویسی (اگر اشتباه نگم اسمش رو) بهشون شدید کمک می‌کنه

LLM (large language model) for co-writing theater noscripts.

کاری از deepmind

GitHub Link