CodeByMe 🛜
الذهاب إلى القناة على Telegram
برنامه نویسی لذت بخش تره یا چایی ؟ . Instagram: codebyme_com Youtube: codebyme
إظهار المزيد922
المشتركون
-124 ساعات
-27 أيام
-1330 أيام
أرشيف المشاركات
922
با کمک AI چه رزومههای تمیزی درست میکنه و ضمناً رایگانه. از لینک زیر وارد سایت بشید:
https://flowcv.com
@codebyme
922
Roadmap.sh added AI tutor to generate personalized course with custom difficulty of user input !
سایت معروف roadmap.sh یه قسمت به نام AI Tutor جدیدا معرفی کرده که میتونید بصورت custom درس مخصوص خودتون رو با درجه سختی دلخواه بسازین و یاد بگیرید. دنیای عجیبی شده :))
#Roadmap #AI #Tutor #Tutorial #Magic #Generator #Personalized #Course #Topic #Difficulty #Level
@codebyme
https://roadmap.sh/ai-tutor
922
مفهوم Trade-off در توسعه نرمافزار
(تعادل میان مزایا و معایب در تصمیمهای فنی)
در توسعه نرمافزار، هیچ تصمیمی رایگان نیست. هر انتخابی، در کنار مزایا، هزینهها و محدودیتهایی هم دارد. Trade-off یعنی برقراری تعادل میان این مزایا و معایب، و انتخاب بهترین گزینه متناسب با شرایط واقعی پروژه.
مثال ساده از دنیای خارج:
وقتی میخواهید خودرویی بخرید، معمولاً باید بین مصرف سوخت پایین و قدرت موتور بالا یکی را قربانی کنید. به ندرت خودرویی پیدا میشود که هر دو ویژگی را به بهترین شکل داشته باشد.
و در دنیای نرمافزار:
- اگر بخواهید سرعت توسعه بالاتر برود، احتمالاً باید کمی از بهینهبودن یا کارایی چشمپوشی کنید.
- اگر انعطافپذیری کامل بخواهید، باید پیچیدگی بیشتری را بپذیرید.
- اگر سراغ فریمورکهای جدید بروید، نوآوری بیشتری به دست میآورید، اما منابع آموزشی و نیروی متخصص کمتری پیدا میکنید.
تفاوت در معیارهای سنجش
نکته مهم دیگر این است که معیارهای سنجش در هر پروژه متفاوت است:
- یک استارتاپ ممکن است سرعت رسیدن به بازار را مهمتر بداند.
- یک سیستم بانکی احتمالاً امنیت و پایداری بلندمدت را در اولویت قرار میدهد.
- یک پروژه تحقیقاتی شاید بیشتر به انعطافپذیری و نوآوری اهمیت دهد.
بنابراین حتی اگر دو تیم روی یک زبان یا فریمورک واحد بحث کنند، ممکن است از زاویههای متفاوتی آن را ارزیابی کنند و به نتایج متفاوتی برسند.
به همین دلیل، انتخاب زبان، ابزار یا فریمورک هیچوقت یک پاسخ مطلق «بهترین» ندارد.
سؤال درست این نیست که کدام بهترین است؟
بلکه این است که کدام گزینه با توجه به نیازهای فعلی پروژه و توان تیم، بهترین تعادل (Trade-off) را فراهم میکند؟
Source
#trade_off
@codebyme
922
تصور کنید در حال انتخاب کتابخانهای برای پروژهتون هستید: React یا Vue؟ Tailwind یا Bootstrap؟ Lodash یا Ramda؟
همیشه این سوال پیش میاد که کدوم یکی ترندتره، بیشتر دانلود میشه، یا جامعه بزرگتری داره؟
امروز میخوام یک ابزار فوقالعاده رو بهتون معرفی کنم:
npmtrends.com
این سایت مثل یک رادار برای اکوسیستم npm عمل میکنه و بهتون کمک میکنه پکیجها و کتابخانههای مختلف رو با هم مقایسه کنید.
فقط کافیه اسامی ابزارهایی که میخواهید را وارد کنید و نرخ دانلود هر پکیج را نسبت به پکیج دیگه مقایسه کنید
همچنین میتونید مشخصات کلیدی دیگر ابزارها مانند ستاره گیتهاب ، آخرین زمان آپدیت و ... مشاهده کنید
مثلا توی این تصویر مقایسه ۲ پکیج تیلویند و بوتسترپ در یک سال اخیر به ما نشون میده
این ابزار نه تنها کمک میکنه بهترین انتخاب رو بکنید، بلکه از روندهای آینده هم آگاهتون میکنه. مثلاً اگر ببینید یک پکیج دانلودهاش داره افت میکنه، میتونید زودتر به پکیجهای مناسب تر سوییچ کنید و پروژهتون رو ایمن نگه دارید.
@codebyme
922
دلیل اینکه در زبانهایی مثل Go یا Rust یا حتی C دچار سردرگمی میشید، بخاطر این هست که میخواهید ساختارهایی که از زبانهای شیگرا در ذهن دارید رو دقیقا به همون شکل در اینها هم داشته باشید. این زبانها هم تا حدی این توهم رو ایجاد میکنند که اینکار شدنی هست؛ و میتوان گفت که همینطور است، ولی فقط در ظاهر!
بسیاری از چیزهایی که شما در زبانهای شیگرا با آنها اشنا شدید، مختص و منحصر به شیگرایی نیستند. صرفا چون شما احتمالا به دلایل تاریخی برنامهنویسی رو با شیگرایی یاد گرفتید، ممکن هست اینطور تصور کنید که این مفاهیم فقط مختص به شی گرایی هستند. در حالی که بیشتر مفاهیمی که در ذهن دارید در هر پارادایم و هر زبانی قابل پیاده سازی هست.
مثلا اگر امروز به یک برنامهنویس Go یا Rust یک پروژهی بانکی یا یک سیستم فروشگاه رو محول کنید، به احتمال زیاد این پروژه رو مبتنی بر DDD انجام خواهد داد! حتی یک برنامهنویس Clojure هم احتمالا همین رویه را دنبال خواهد کرد! الان احتمالا در ذهن شما این سوال پیش آمده که DDD؟ چطور همچین چیزی ممکن هست؟ مگه این برای شی گرایی نیست؟ خیر، «شما» اون رو با شی گرایی یاد گرفتید، ولی خودش یک ایدهی عمومی است.
شما به شکلی آموزش دیدهاید که یونیتهای کد را در قالب کلاس ها ببینید. و وقتی به زبانهایی میرسید که دارای کلاس نیستند، اولین چیزی که به فکرتان میرسد این است که کلاس را در آنها شبیه سازی کنید. درست است؟
این دیدگاه، شما را دچار مشکل میکند، و دلیل اصلی اش این است که شما حتی در زبانهای شیگرا هم به درستی درک نکرده بودید که کلاس چیست! و همان دیدگاه اشتباه خود درباره کلاس رو به سایر زبانها هم انتقال میدهید!
وقتی حرف از کلاس میشود، بیشتر افراد میکنند کلاس یک بلاک از کد است که تعدادی فیلد و متد را بین دو {} گرد هم آورده است.
اما کسی سوال نمیکند خب چرا اینکار را کردند؟ فقط چون میخواستند یک سری فیلد داشته باشند و یک سری تابع بتوانند روی انها کار کنند؟
خب این رو که از قدیم در همه زبانها داشتیم. مگر اصلا جور دیگری میشود برنامه نویسی کرد؟ در تمام زبانها یک سری دیتا داریم و یک سری تابع که روی آن دیتا کار میکنند. قدیمی ترین کد C ای که میتوانید پیدا کنید را باز کنید، احتمالا در آن یک استراکت پیدا میکنید به همراه تعدادی تابع که روی آن استراکت کار میکنند. این رویه قبل از شی گرایی هم وجود داشته... فقط چون این دو را کنار هم درون {} قرار میدهید اسمش میشود کلاس؟ یعنی فقط چون میخواستند کنار هم باشن؟ که تنها نباشن؟ غصه نخورن؟ فکر نمیکنید شاید دلایل مهمتری برای این موضوع وجود داشته؟
ویژگیهایی وجود دارد که باعث میشود کلاس، کلاس بشود:
۱. کلاس دارای مکانیزم وراثت است.
۲. کلاس پلی مورفیسم مبتنی بر وراثت را فراهم میکند (متدهای virtual)
۳. از روی کلاس، میتوان آبجکتی در حافظه تولید کرد.
۴. کلاس آبجکتها را دسته بندی میکند (برای همین اسمش class است). یعنی باید بتوان جواب این سوال را جویا شد: ایا فلان آبجکت جزو فلان کلاس است؟
۵. آبجکتهای ساخته شده از روی کلاس، دارای لایف تایم متفاوتی از سایر بلاک ها هستند. ابجکتها حالت رفرنس دارند. به این معنی که تقریبا در تمام زبانها، در هیپ قرار میگیرند.
اینکه دیتا و توابع را کنار هم و در یک بلاک به اسم کلاس جمع کردناند، به خاطر این است که یک کانتکست یکپارچه پدید آورند که در قالب آن بتوانند همهی ویژگیهای بالا را برآورده کنند.
اینکه شما یک استراکت بسازید، و چند تابع تعریف کنید که روی آن استراکت کار کنند، کدام یک از ویژگیهای بالا را شامل میشود؟ این دو بخش لزومی هم ندارد که جدا از هم باشند. مثلا در zig میتوانید توابع را عین یک کلاس درون همان بلاک مربوط به استراکت قرار دهید. ولی باز هم در صورت انجام اینکار، تبدیل به کلاس نمیشود چون هیچکدام از ویژگیهای بالا را ندارد.
یا مثلا در C یا سایر زبانها، فیلدها و متدها را در ماژولها گرد هم میاورند. ایا با اینکار آن ماژول تبدیل به کلاس شده است؟
اتفاقی که این وسط افتاده این است:
۱. شما در حین یادگیری شی گرایی بدرستی درک نکردید که کلاس چیست!
۲. بر مبنای آن درک اشتباه، فکر کردید شی گرایی یعنی کنار هم قرار دادن فیلدها و متدها در یک بلاک.
۳. اصرار به این دارید که این درک اشتباه را در زبانهایی که اصلا دارای کلاس نیستند پیاده سازی کنید.
این همان جایی است که در زبانهایی مانند Go و Rust و Zig و C سایرین به مشکل بر میخورید. برای همین هست که میگویند اینها را با زبانهای شی گرا اشتباه نگیرید. چون اینها از نظر ظاهری، شاید شرایطی را فراهم کنند که به چشم شما مشابه چیزی باشد که در شی گرایی به یاد داشتید، ولی از نظر Semantics با زبانهای شی گرا متفاوت اند.
@codebyme
922
این پیام بسیار بسیار آموزنده خواهد بود. به زیاد بودن متن توجه نکنید و حتما آن را بخوانید (اگر بیش از یکسال هست که وارد دنیای برنامه نویسی شدید) ...
👇🏻👇🏻👇🏻👇🏻👇🏻👇🏻
922
رئیس دپارتمانمون رو میزش یه کوزه در بستهاس روش نوشته «خاکستر دانشجوهای دردسرساز»
💬mamoli
@codebyme
922
لیتکد یکی از بهترین جاها برای تمرین الگوریتمه. این ریپو جواب بالای هزار تا از مسئلههاشو داره. اگه نمیدونی از کجا شروع کنی، اول جوابارو یه نگاه بنداز، بعد خودت امتحان کن. همین میتونه شروع مسیرت باشه:
https://github.com/haoel/leetcode
@codebyme
922
#sarkhat
اولین قدم در مسیر دِوآپس
یادگیری
Linux، اساس همه چیز
سفر به سوی Cloud Computing با انرژی و انگیزه
تجربیات تازهکارانه برای رشد و موفقیت در دنیای فناوری
https://codebyme.com/sarkhat/اولین-قدم-من-در-دوآپس-داستان-یک-تازهکار
@codebyme922
جدا از مهندسی پشت تلگرام که بهینه نوشته شده، تلگرام چیزی داره به اسم Update Queue. چیزی که ۱ سال از دوران جوونیم رو صرف مهندسی معکوسش کردم.
تلگرام برای پوش کردن تغییرات مثل پیام جدید، ادیت، ری اکشن، تایپینگ و… به کلاینتها از سرویس Updates تو پروتکل MTProto استفاده میکنه، ایده ی کلی و کلیدی خیلی ساده اس و اینه که کلاینت ها یه state محلی نگه میدارن و آپدیتارو دقیقا با ترتیب درست اعمال میکنن؛ اگه شکافی بینشون افتاد، Difference میگیرن و دوباره پرش میکنن.
چرا اینکارو کرده و کلا چالشا چیه؟
• ترتیبش مهمه چون ممکنه یه اپدیت وابسته به چیزی باشه که توی خود همون پچ میاد
• تحویل دقیق باید انجام بشه و هیچی گم نشه
• مقیاسش هم میلیونها کاربر همزمان باید بگیرنش، مثل کانال های بزرگ
از اونجایی که هر پیامرسان منبع عظیمی از اتفاقاتیه که هر لحظه میوفته ما میتونیم اسم این اتفاقات رو event بزاریم. تلگرام هم یه پیامرسان مولتی کلاینته، یعنی هر کاربر میتونه چندین دیوایس برای یه حساب داشته باشه، پس وقتی یه ایونت اتفاق میوفته که باید یه کاربر از اون خبردار بشه باید اون ایونت رو به دیوایس های دیگه ی کاربر هم بفرسته، حدودا با مرتبه زمانی On^2.
مکانیزم اینجوریه که وقتی دیوایسی انلاین باشه و سوکت همون سوکتی باشه که keep alive هست یا اخرین rpc رو کال کرده سرور ایونت رو توی queue برای اون دیوایس نگه نمیداره و مستقیم میفرسته به کلاینت، حالا از اونجایی که کلاینت های دیگه ممکنه افلاین باشن یا حتی توی بکگراند پروسسشون کیل شده باشه عقب میمونن. حالا وقتی اون دیوایسی که عقب مونده بود با باز شدن سوکتش درخواست گرفتن اپدیت هارو وقتی که افلاین بوده رو از سرور میکنه و اطلاعات لوکالش رو میفرسته به سرور، من برای ساده شدنش اینجوری میگم که دیوایس میاد به سرور میگه من تا این زمان t رو داشتم و بعد این رو بهم بده، سرور هم میاد حساب کتابش رو میکنه و جواب رو توی یه پچ میفرسته! حالا چی توی این پچ هست و چی رو میفرسته رو میتونم یه رشته توییت دیگه در موردش بزنم.
حالا اگه اعدادی که توی پچ میاد با اعداد توی کلاینت نخونه عملا میگیم گپ اتفاق افتاده، برای همین هم کلاینت باید رکویست getDiff رو بزنه.
رکویست updates.getDifference به کلاینت اجازه میده بگه:
من الان pts = X و seq = Y هستم و هر چی بین این و حالت جدید هست بهم بده.
• سرور ممکنه جواب بده:
difference: همه ی آپدیت های گمشده
differenceSlice: بخشی از آپدیت ها یعنی هنوز باید به فچ کردن ادامه بدی
differenceEmpty: چیزی تغییر نکرده
جالبترش اینه که توی نسخه های جدیدترش برای کانال ها مکانیسم جدا getChannelDifference هست، چون هر کانال pts مستقل داره و این باعث میشه شما فقط کانال هایی رو بگیری که تغییر کردن! برای سوپر گروه هم مکانیزم همینه.
این باعث میشه حتی اگر چند ساعت آفلاین باشی، بعد از اتصال دوباره دقیقاً همهچی رو بگیری و هیچ پیامی رو از دست ندی
حتی با packet loss یا reconnect، state کلاینت خراب نمیشه و سرور مجبور نیست برای هر کلاینت همه چی رو دوباره بفرسته. فقط gap ها sync میشن
@codebyme
922
امروز یکی از همکارانم سوال خوبی پرسید که فکر میکنم دغدغه خیلیهاست:
"فرق واقعی Async و Concurrency چیه؟ مگه هر دو به معنی انجام همزمان کارها نیستن؟"
این دو مفهوم اغلب با هم اشتباه گرفته میشن. بذارید با یک مثال ساده تفاوتشون رو باز کنم:
۱. Synchronous vs. Asynchronous
این مفاهیم درباره انتظار کشیدن هستن.
Sync
مثل اینه که بری کافه، قهوه سفارش بدی و همونجا جلوی پیشخوان منتظر بمونی تا آماده بشه و تحویل بگیری.
تا قهوه رو نگیری، هیچ کار دیگهای نمیکنی.
Async
سفارش میدی، یک پیجر (Pager) میگیری و میری سر میزت مینشینی.
در این فاصله میتونی ایمیلهاتو چک کنی.
هر وقت قهوهات آماده شد، پیجر بهت خبر میده.
تو منتظر نموندی و از زمانت استفاده کردی.
۲. Concurrency
این مفهوم درباره مدیریت چند کار در یک بازه زمانی هست.
باریستای کافه رو در نظر بگیرید:
اون همزمان هم سفارش شما رو آماده میکنه، هم سفارش نفر بعدی رو میگیره و هم شیر رو برای یک سفارش دیگه گرم میکنه.
در واقع اون با جابجایی سریع بین کارها (Context Switching)، چند وظیفه رو پیش میبره.
این یعنی همروندی.
نکته کلیدی
برنامهنویسی Async یکی از راههای رسیدن به Concurrency هست.
درک این تفاوت، در طراحی سیستمهای مدرن مثل میکروسرویسها یا پایپلاینهای پردازش دیتا، یک مزیت فوقالعاده است.
این درک به شما کمک میکنه تا بین ابزارهایی مثل Kafka, gRPC یا WebSockets انتخاب درستی داشته باشید و سیستمی بسازید که هم Scalable و هم Reliable باشه.
@codebyme
متاح الآن! بحث تيليغرام 2025 — أهم رؤى العام 
