code cache | کد کش – Telegram
code cache | کد کش
875 subscribers
183 photos
86 videos
6 files
49 links
Download Telegram
1. مالتی‌تردینگ (Multithreading)

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

خوبی‌ها:

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

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


بدی‌ها:

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

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

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

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

خوبی‌ها:

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


بدی‌ها:

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

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

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

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

خوبی‌ها:

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

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


بدی‌ها:

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

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

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

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

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

@code_cache
👍5
زمان جومونگ هرروز Daily داشتن

@code_cache
🤣5
This media is not supported in your browser
VIEW IN TELEGRAM
وقتی پروژرو رو لوکال ران میکنم vs وقتی میبرم رو سرور

@code_cache
🤣4
This media is not supported in your browser
VIEW IN TELEGRAM
وب سایت levels.fyi‎ که به جویندگان کار کمک میکنه دستمزد در شرکت‌های مختلف را مقایسه کنن یک heatmap حقوق اضافه کرده که میتونید بازه حقوقی برای شغلهای مختلف را در شهرهای امریکا ببینید.

@code_cache
👍4
کی از 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
👍4
This media is not supported in your browser
VIEW IN TELEGRAM
وقتی از بچه های کامپیوتر درمورد ارتباط با خانواده میپرسی:

@code_cache
😁4
This media is not supported in your browser
VIEW IN TELEGRAM
public class person extends car {

😂😂😂

@code_cache
🤣5
🤣5
ماشین لرنینگ کار نیستم. فقط گاها با رفقا جمع میشیم، دو سه ایپوک منم میزنم.

@code_cache
👍5
This media is not supported in your browser
VIEW IN TELEGRAM
مقایسه سرعت سی‌پی‌یو در خواندن اطلاعات از مموری و SSD

@code_cache
👍4🤯1
آسمون بیاد زمین، زمین بره آسمون فرانت برنامه نویس نیست.

@code_cache
👍6👎1
😏😂

@code_cache
👍3👎1
code cache | کد کش
😂😂😂 @code_cache
دهن سرویس اگه بک برنامه‌نویس نیست پس نقاشا برنامه‌نویسن؟
نکنه دیزاینر و تستر و پهپ کار و وردپرس کارم برنامه‌نویسن😂😂

@code_cache
👍4👎1