مهاجرت نکنید غربته، پزشکی نخونید زحمت زیاد داره، برنامه‌نویس نشید هوش‌مصنوعی جاتون رو می‌گیره. شیره و تریاک خوبه.

@code_cache

تا چشم کار می‌کنه فقط زیبایی دیده می‌شه🥹

@code_cache

ویدیوهای آموزشی رو از یه حدی نمیشه سریعتر کرد (وگرنه کلمات مبهم میشن)، و بعضی از این ویدیوها که وسطش سکوت و مکث زیاد داره (بخصوص کورس‌های دانشگاهی) واقعا خیلی روی مخه. یه ابزاری گیر آوردم اتومات همه این silent momentها رو حذف میکنه، باقی ویدیو رو هم تسریع میکنه و خروجی ایده‌آل میده. اگه yt-dlp از قبل نصب داشته باشی هم که میتونی مستقیم لینک یوتیوب بدی بهش، دانلود و ادیت میکنه خروجی تمیز و خلاصه میده بهت.

https://auto-editor.com
https://github.com/yt-dlp/yt-dlp

@code_cache

به مفاهیم بلاک‌چین علاقه دارید از بیس شروع کنیم باهم یاد بگیریم؟

ی بنده خدایی ولتش هک شده و ۴۰،۰۰۰ دلارش و زدن،
روشی که باهاش هکش کردن ممکنه برای خیلیامون پیش بیاد حتما حواستون باشه.

@code_cache

پیشنهادم اینه که هروقت خواستید روی پروژه کسی که نمیشناسید کار کنید، روی ی سرور ساعتی پروژه رو بیارید بالا و باهاش کار کنید.
vscode ی حالتی داره که میتونید با ssh
مستقیم کد بزنید و خییییلیییی کاربردیه.

@code_cache

شرکت SpaceX به مناسبت فرود موفقیت آميز بوستر Super Heavy روی بازو‌های برج پرتاب، یک بازی ساده هم برای تلاش برای فرود اون طراحی کرده که میتونین اون رو از لینک زیر انجام بدین.

starshipthegame.spacex.com

@code_cache

تا قبل از نسخه 3.13 پایتون، برنامه‌های مالتی‌ترد خیلی کندتر اجرا می‌شدند و دلیل اصلیش هم GIL یا Global Interpreter Lock بود. این قفل جلوی اجرای همزمان تردها رو می‌گرفت تا Race Condition پیش نیاد، ولی خب باعث می‌شد تو برنامه‌های چندنخی نتونی از تمام قدرت CPU استفاده کنی.

تو نسخه 3.13 این مشکل رو با آپشنال کردن GIL حل کردن. علاوه بر اون، JIT هم اضافه شده که کارش اینه بعد از تبدیل کد به بایت‌کد، قسمت‌های پرکاربرد (Hot Code) رو پیدا می‌کنه و همون‌ها رو مستقیم کامپایل می‌کنه و می‌ده به CPU. این‌جوری سرعت برنامه‌ها خیلی بیشتر می‌شه چون دیگه مفسر پایتون وسط کار نیست.

@code_cache

در پایتون، سه روش رایج برای انجام کارهای هم‌زمان (Concurrency) و موازی (Parallelism) وجود دارد: مالتی‌تردینگ (Multithreading)، مالتی‌پراسسینگ (Multiprocessing)، و ای‌سینک (Asynchronous Programming). هر کدام از این روش‌ها برای نوع خاصی از وظایف مناسب هستند. حالا بیایید هر کدام را توضیح دهیم و مقایسه کنیم:

@code_cache

1. مالتی‌تردینگ (Multithreading)

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

خوبی‌ها:

اگه برنامه‌ات بیشتر منتظر چیزیه (مثلا منتظر اینترنت یا خوندن یه فایل)، خیلی کمک می‌کنه.

مصرف حافظه کمتره، چون همه توی یه اتاق کار می‌کنن (همون محیط مشترک).


بدی‌ها:

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

وقتی چند نفر (یا ترد) از یه منبع مشترک استفاده کنن، ممکنه دعواشون بشه! یعنی مشکلاتی مثل قفل شدن (deadlock) یا برخورد داده‌ها (race condition) پیش میاد.

@code_cache

2. مالتی‌پراسسینگ (Multiprocessing)

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

خوبی‌ها:

اینجا دیگه خبری از اون قفل GIL نیست و می‌تونی واقعاً از قدرت همه هسته‌های CPU استفاده کنی. خیلی خوبه برای کارهای سنگین مثل پردازش تصویر یا محاسبات عددی.


بدی‌ها:

چون هر پراسس محیط جدا داره، اگه بخوای اطلاعات بینشون رد و بدل کنی، این کار یکم کندتره.

ساختن پراسس‌های بیشتر یعنی حافظه بیشتری هم می‌خوای.

@code_cache

3. برنامه‌نویسی غیرهمزمان (Async)

برنامه‌نویسی ای‌سینک یه جور بازیه که توی یه ترد اجرا می‌شه و به برنامه می‌گه: "تا این کار تموم بشه، برو یه کار دیگه بکن!" یعنی اگه منتظر اینترنتی یا منتظر خوندن فایلی، لازم نیست بیکار بشینی.

خوبی‌ها:

خیلی مناسب کارهایی مثل شبکه یا خوندن/نوشتن فایل که توش منتظر I/O هستی (دریافت و ارسال داده).

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


بدی‌ها:

اگه با پایتون تازه‌کاری، ممکنه اولش یه کم گیج‌کننده باشه.

این روش برای کارای سنگین که پردازنده رو زیاد درگیر می‌کنه، خوب نیست، چون فقط یه ترد داری و اونم تحت تاثیر همون GIL می‌مونه.

@code_cache

فرقشون چیه و کِی کدومو استفاده کنیم؟

اگه کارت بیشتر با ورودی/خروجی (I/O) سر و کار داره، مثل وقتی که از اینترنت داده می‌گیری یا فایل می‌خونی، multithreading یا async به کارت میاد.

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

@code_cache

زمان جومونگ هرروز Daily داشتن

@code_cache

وقتی پروژرو رو لوکال ران میکنم vs وقتی میبرم رو سرور

@code_cache

وب سایت levels.fyi‎ که به جویندگان کار کمک میکنه دستمزد در شرکت‌های مختلف را مقایسه کنن یک heatmap حقوق اضافه کرده که میتونید بازه حقوقی برای شغلهای مختلف را در شهرهای امریکا ببینید.

@code_cache

اسکرام مستر بعد از نرسیدن تسکا:

@code_cache

کی از Git Rebase استفاده کنیم و کی از Git Merge؟

گاهی توی کار با Git با این سؤال مواجه می‌شیم که کی بهتره از rebase استفاده کنیم و کی merge؟ این موضوع می‌تونه روی خوانایی و ساختار تاریخچه پروژه تاثیر زیادی بذاره.

وقتی که می‌خوایم تاریخچه‌ای تمیز و خطی داشته باشیم، از git rebase استفاده می‌کنیم. مثلاً فرض کنید در حال کار روی یک شاخهٔ جانبی (feature) هستیم که از شاخهٔ "main" ساخته شده و در این مدت، تغییرات جدیدی در "main" رخ داده است. اگر از rebase استفاده کنیم، تغییرات شاخهٔ "feature" به گونه‌ای دوباره اعمال می‌شوند که انگار بعد از آخرین تغییرات شاخهٔ "main" انجام شده‌اند. این کار کمک می‌کنه که تاریخچه پروژه به شکلی خطی و ساده باقی بمونه و دیدن اینکه چه تغییراتی و به چه ترتیبی انجام شده، راحت‌تر باشه.

اما باید با git rebase با احتیاط رفتار کنیم، چون در صورت استفاده نادرست می‌تونه مشکلات جبران‌ناپذیری ایجاد کنه. به‌ویژه، زمانی که چند نفر به طور همزمان روی یک شاخه کار می‌کنند، استفاده از rebase می‌تونه منجر به سردرگمی و مشکلات ترکیب (merge conflict) بشه. بنابراین، بهتره زمانی از rebase استفاده کنیم که با نحوهٔ عملکرد دقیق اون آشنایی کافی داشته باشیم.

از طرف دیگه، وقتی که می‌خوایم دو شاخه رو با هم ترکیب کنیم و دوست داریم که تاریخچهٔ هر دو شاخه و تغییراتشون حفظ بشه، git merge بهترین انتخابه. این روش مخصوصاً زمانی مناسب هست که بخوایم مشارکت چندین توسعه‌دهنده و تاریخچه کارهای انجام شده روی هر شاخه رو حفظ کنیم. merge به ما این امکان رو می‌ده که به وضوح ببینیم که در چه زمانی دو شاخه با هم ادغام شده‌اند و هیچ تغییری از دست نرفته است.

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

@code_cache

وقتی از بچه های کامپیوتر درمورد ارتباط با خانواده میپرسی:

@code_cache