Microfrontend.ir
معماران نرم‌افزار که از موقعیت‌های فنی به نقش‌های رهبری منتقل می‌شوند نکات مهمی را باید در نظر داشته باشند. در این نقش‌ها، ارتباط مؤثر به اندازهٔ مهارت‌های فنی اهمیت دارد. نکات کلیدی برای بهبود مهارت‌های ارتباطی در این نقش عبارتند از: 1. قدرت حضور را درک…
خرابی در تمامی اجزای یک سیستم پیچیده اجتناب ناپذیر است؛ از سخت‌افزار و نرم‌افزار گرفته تا خطاهای انسانی و محدودیت‌های شبکه. تاکید اصلی بر مهندسی تاب‌آوری است؛ یعنی طراحی و پذیرش فعالانه سیستم‌هایی که توانایی واکنش مناسب در برابر خرابی‌ها را دارند.
سخت‌افزار قابل اعتماد نیست، بنابراین ما از افزونگی (Redundancy) استفاده می‌کنیم تا در برابر خرابی‌های سخت‌افزاری بقا داشته باشیم، اما این کار احتمال وجود حداقل یک خرابی در هر زمان را افزایش می‌دهد. نرم‌افزار نیز خطاپذیر است، و از آنجا که برنامه‌های ما از نرم‌افزار تشکیل شده‌اند، مستعد خطا هستند. برای نظارت بر خرابی‌ها، نرم‌افزارهای نظارتی را اضافه می‌کنیم، اما این نظارت هم از جنس نرم‌افزار است و خود می‌تواند دچار خرابی شود.
انسان‌ها هم مرتکب اشتباه می‌شوند، بنابراین برای کاهش خطاها از اتوماسیون استفاده می‌کنیم؛ اما اتوماسیون احتمال خطای انجام ندادن کاری را افزایش می‌دهد. هیچ سیستم اتوماتیکی نمی‌تواند به همان گستره‌ای که انسان‌ها قادرند واکنش نشان دهند.
شبکه‌ها از سخت‌افزار، نرم‌افزار و کابل‌های طولانی تشکیل شده‌اند، بنابراین آن‌ها نیز دچار خطا می‌شوند. هر مکانیسم ایمنی که برای کاهش یک نوع خطا استفاده می‌کنیم، نوع جدیدی از خطا را اضافه می‌کند.
پس، با پذیرش این که سیستم‌ها قطعاً دچار خرابی می‌شوند، می‌توانیم واکنش سیستم‌ها به این خرابی‌ها را طراحی کنیم؛ همانطور که مهندسان خودرو مناطق شکست (Crumple Zones) را برای محافظت از سرنشینان طراحی می‌کنند، می‌توانیم حالت‌های شکست ایمنی را ایجاد کنیم که خسارت را محدود کرده و از بقیه سیستم محافظت کنند.
#TIP-08
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
سخت‌افزار قابل اعتماد نیست، بنابراین ما از افزونگی (Redundancy) استفاده می‌کنیم تا در برابر خرابی‌های سخت‌افزاری بقا داشته باشیم، اما این کار احتمال وجود حداقل یک خرابی در هر زمان را افزایش می‌دهد. نرم‌افزار نیز خطاپذیر است، و از آنجا که برنامه‌های ما از نرم‌افزار تشکیل شده‌اند، مستعد خطا هستند. برای نظارت بر خرابی‌ها، نرم‌افزارهای نظارتی را اضافه می‌کنیم، اما این نظارت هم از جنس نرم‌افزار است و خود می‌تواند دچار خرابی شود.
انسان‌ها هم مرتکب اشتباه می‌شوند، بنابراین برای کاهش خطاها از اتوماسیون استفاده می‌کنیم؛ اما اتوماسیون احتمال خطای انجام ندادن کاری را افزایش می‌دهد. هیچ سیستم اتوماتیکی نمی‌تواند به همان گستره‌ای که انسان‌ها قادرند واکنش نشان دهند.
شبکه‌ها از سخت‌افزار، نرم‌افزار و کابل‌های طولانی تشکیل شده‌اند، بنابراین آن‌ها نیز دچار خطا می‌شوند. هر مکانیسم ایمنی که برای کاهش یک نوع خطا استفاده می‌کنیم، نوع جدیدی از خطا را اضافه می‌کند.
پس، با پذیرش این که سیستم‌ها قطعاً دچار خرابی می‌شوند، می‌توانیم واکنش سیستم‌ها به این خرابی‌ها را طراحی کنیم؛ همانطور که مهندسان خودرو مناطق شکست (Crumple Zones) را برای محافظت از سرنشینان طراحی می‌کنند، می‌توانیم حالت‌های شکست ایمنی را ایجاد کنیم که خسارت را محدود کرده و از بقیه سیستم محافظت کنند.
#TIP-08
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
❤12
Microfrontend.ir
خرابی در تمامی اجزای یک سیستم پیچیده اجتناب ناپذیر است؛ از سخت‌افزار و نرم‌افزار گرفته تا خطاهای انسانی و محدودیت‌های شبکه. تاکید اصلی بر مهندسی تاب‌آوری است؛ یعنی طراحی و پذیرش فعالانه سیستم‌هایی که توانایی واکنش مناسب در برابر خرابی‌ها را دارند. سخت‌افزار…
به محض اینکه صحبت از کاهش هزینه‌ها می‌شود، مدیر پروژه می‌پرسد: «آیا واقعاً به این نیاز داریم؟» و برای «این» هر چیز مهم و ضروری که در سیستم لازم است، جایگزین می‌شود؛ از جمله مجوزهای نرم‌افزاری، سرورهای اضافی، پشتیبان‌گیری‌های خارج از سایت یا منابع برق.
در چنین شرایطی، پاسخ درست این است که بگوییم: «بله، به آن نیاز داریم.» اما اکثر اوقات، پاسخ متفاوتی ارائه می‌دهیم. چون به‌عنوان مهندسان، به مصالحه و انتخاب‌های مختلف عادت کرده‌ایم. به همین دلیل به جای پاسخ قاطعانه، شروع به توضیح دادن و توجیه می‌کنیم و معمولاً مدیر بعد از کلمه «خب...» دیگر گوش نمی‌دهد.
مشکل اصلی این است که ما کار خود را به‌عنوان مهندسی و حل مسأله می‌بینیم، در حالی که مدیر پروژه آن را به چشم یک مذاکره نگاه می‌کند.
«وقتی مدیر پروژه می‌پرسه "آیا واقعاً به این نیاز داریم؟" به جای توضیح فنی، بگو "بله، بدون این، سیستم سه بار در روز سقوط میکنه، مخصوصاً وسط جلسه هیئت مدیره!" گاهی مذاکره یعنی قاطعیت، نه توضیح!
#TIP-09
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
در چنین شرایطی، پاسخ درست این است که بگوییم: «بله، به آن نیاز داریم.» اما اکثر اوقات، پاسخ متفاوتی ارائه می‌دهیم. چون به‌عنوان مهندسان، به مصالحه و انتخاب‌های مختلف عادت کرده‌ایم. به همین دلیل به جای پاسخ قاطعانه، شروع به توضیح دادن و توجیه می‌کنیم و معمولاً مدیر بعد از کلمه «خب...» دیگر گوش نمی‌دهد.
مشکل اصلی این است که ما کار خود را به‌عنوان مهندسی و حل مسأله می‌بینیم، در حالی که مدیر پروژه آن را به چشم یک مذاکره نگاه می‌کند.
«وقتی مدیر پروژه می‌پرسه "آیا واقعاً به این نیاز داریم؟" به جای توضیح فنی، بگو "بله، بدون این، سیستم سه بار در روز سقوط میکنه، مخصوصاً وسط جلسه هیئت مدیره!" گاهی مذاکره یعنی قاطعیت، نه توضیح!
#TIP-09
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
👍11
Microfrontend.ir
به محض اینکه صحبت از کاهش هزینه‌ها می‌شود، مدیر پروژه می‌پرسد: «آیا واقعاً به این نیاز داریم؟» و برای «این» هر چیز مهم و ضروری که در سیستم لازم است، جایگزین می‌شود؛ از جمله مجوزهای نرم‌افزاری، سرورهای اضافی، پشتیبان‌گیری‌های خارج از سایت یا منابع برق. در…
تعریف دقیق نیازمندی‌ها در معماری نرم‌افزار حیاتی و عباراتی مانند «سریع»، «پاسخگو» یا «قابل گسترش» به خودی خود کافی نیستند؛ زیرا معیاری برای سنجش آن‌ها وجود ندارد. با این حال، کاربران همچنان این ویژگی‌ها را می‌خواهند. نقش معمار این است که این ویژگی‌ها را تا حد امکان فراهم کرده و بین تضادهای احتمالی آن‌ها تعادل ایجاد کند.
اگر این نیازها به‌طور مشخص و قابل اندازه‌گیری بیان نشوند، هیچ مبنایی برای پذیرش سیستم توسط کاربران وجود نخواهد داشت و راهنمایی ارزشمندی از مهندسان در حین کار گرفته می‌شود. در نتیجه، معماران باید تلاش کنند این نیازها را با سوالاتی مانند «چقدر؟»، «در چه مدت زمانی؟»، «چند بار؟»، «چقدر سریع؟» و غیره به مقادیر دقیق تبدیل کنند. اگر این اطلاعات در برنامه تجاری سیستم نیست، باید علت آن را جستجو کرد و آن‌ها را دریافت.
همچنین باید نیازمندی‌های نامشخص را به‌صورت محدوده‌ای تعریف کرد: حداقل، مطلوب، و حداکثر. اگر این محدوده‌ها مشخص نشوند، یعنی رفتار مورد نظر سیستم به‌درستی درک نشده است. این کار ممکن است وقت‌گیر و هزینه‌بر باشد، اما اگر هیچ‌کس به‌اندازه کافی به عملکرد اهمیت ندهد که هزینه تست‌های عملکرد را بپردازد، احتمالاً عملکرد مهم نیست و می‌توان روی جنبه‌های دیگر تمرکز کرد.
برای مثال، نیازمندی‌هایی مثل: «باید به ورودی کاربر در حداکثر ۱۵۰۰ میلی‌ثانیه پاسخ دهد. تحت بار عادی (تعریف شده به‌عنوان...) زمان پاسخگویی بین ۷۵۰ تا ۱۲۵۰ میلی‌ثانیه باشد. پاسخگویی زیر ۵۰۰ میلی‌ثانیه توسط کاربر قابل تشخیص نیست، بنابراین برای کمتر از این مقدار هزینه نخواهیم کرد»، نیازمندی‌های واقعی هستند. "نیازمندی‌هایی مثل 'سریع' و 'قابل گسترش' بدون معیار مشخص بی‌فایده‌اند. برای تعریف درست، اعداد و محدوده‌ها را مشخص کنید: چقدر سریع؟ چند کاربر؟ چه زمانی؟ اگر برای تست عملکرد هزینه نمی‌شود، شاید اصلاً مهم نباشد."
#TIP-10
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
اگر این نیازها به‌طور مشخص و قابل اندازه‌گیری بیان نشوند، هیچ مبنایی برای پذیرش سیستم توسط کاربران وجود نخواهد داشت و راهنمایی ارزشمندی از مهندسان در حین کار گرفته می‌شود. در نتیجه، معماران باید تلاش کنند این نیازها را با سوالاتی مانند «چقدر؟»، «در چه مدت زمانی؟»، «چند بار؟»، «چقدر سریع؟» و غیره به مقادیر دقیق تبدیل کنند. اگر این اطلاعات در برنامه تجاری سیستم نیست، باید علت آن را جستجو کرد و آن‌ها را دریافت.
همچنین باید نیازمندی‌های نامشخص را به‌صورت محدوده‌ای تعریف کرد: حداقل، مطلوب، و حداکثر. اگر این محدوده‌ها مشخص نشوند، یعنی رفتار مورد نظر سیستم به‌درستی درک نشده است. این کار ممکن است وقت‌گیر و هزینه‌بر باشد، اما اگر هیچ‌کس به‌اندازه کافی به عملکرد اهمیت ندهد که هزینه تست‌های عملکرد را بپردازد، احتمالاً عملکرد مهم نیست و می‌توان روی جنبه‌های دیگر تمرکز کرد.
برای مثال، نیازمندی‌هایی مثل: «باید به ورودی کاربر در حداکثر ۱۵۰۰ میلی‌ثانیه پاسخ دهد. تحت بار عادی (تعریف شده به‌عنوان...) زمان پاسخگویی بین ۷۵۰ تا ۱۲۵۰ میلی‌ثانیه باشد. پاسخگویی زیر ۵۰۰ میلی‌ثانیه توسط کاربر قابل تشخیص نیست، بنابراین برای کمتر از این مقدار هزینه نخواهیم کرد»، نیازمندی‌های واقعی هستند. "نیازمندی‌هایی مثل 'سریع' و 'قابل گسترش' بدون معیار مشخص بی‌فایده‌اند. برای تعریف درست، اعداد و محدوده‌ها را مشخص کنید: چقدر سریع؟ چند کاربر؟ چه زمانی؟ اگر برای تست عملکرد هزینه نمی‌شود، شاید اصلاً مهم نباشد."
#TIP-10
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
👍7
ByteByteGo-Big-Archive-System-Design-2023 (2).pdf
60.2 MB
مجموعه مقالات سال ۲۰۲۳ آقای Alex Xu درباره سیستم دیزاین. ایشون یکی از شناخته‌شده‌ترین آدم‌ها در مارکت سیستم دیزاینه و کتابهاش بست‌سلرن!
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
🔥15
در یکی دو هفته آینده یک مینی پلی‌لیست در مورد ضرورت و مفاهیم بنیادین Observability در دنیای مدرن نرم‌افزار با تمرکز بر OpenTelemetryخواهیم داشت
* پلی‌لیست‌های باز قبلی رو هم به مرور آپدیت خواهم کرد. بویژه گو و پستگرس.
© @microfrontend_ir
* پلی‌لیست‌های باز قبلی رو هم به مرور آپدیت خواهم کرد. بویژه گو و پستگرس.
© @microfrontend_ir
❤18👍5🔥1💯1
@IIIllIlll زحمت کشیدن یک ریپو خوب برای آموزش او ار ام جنگو ساختن
https://github.com/rz-k/django-orm-tutorial
https://github.com/rz-k/django-orm-tutorial
🔥7❤1
Observability در فضای Cloud Native
به زبان ساده، Observability توانایی مشاهده و تحلیل وضعیت داخلی یک سیستم از طریق داده‌هایی است که آن سیستم تولید می‌کند. در فضای Cloud Native، سیستم‌ها از مجموعه‌ای از میکروسرویس‌ها و زیرساخت‌های پویا تشکیل شده‌اند که نیاز به نظارت دقیق و لحظه‌ای دارند. Observability به شما کمک می‌کند نه تنها بدانید چه چیزی اشتباه است، بلکه دلیل وقوع آن را نیز پیدا کنید.
تفاوت Observability و Monitoring
در حالی که Monitoring برای جمع‌آوری و مشاهده معیارهای از پیش تعریف‌شده (مثل استفاده از CPU یا تعداد درخواست‌ها) طراحی شده است، Observability بر قابلیت مشاهده و تحلیل داده‌های خام برای کشف الگوهای جدید تمرکز دارد. این مفهوم به تیم‌ها اجازه می‌دهد به جای پیش‌بینی همه سناریوها، در زمان وقوع مشکلات داده‌های لازم را جمع‌آوری و تحلیل کنند.
Video Link: https://youtu.be/UK71422S-rY
PlayList: https://www.youtube.com/playlist?list=PLJ9zDGwhhsBy6YIfteatuV50ezQODRsEQ
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
به زبان ساده، Observability توانایی مشاهده و تحلیل وضعیت داخلی یک سیستم از طریق داده‌هایی است که آن سیستم تولید می‌کند. در فضای Cloud Native، سیستم‌ها از مجموعه‌ای از میکروسرویس‌ها و زیرساخت‌های پویا تشکیل شده‌اند که نیاز به نظارت دقیق و لحظه‌ای دارند. Observability به شما کمک می‌کند نه تنها بدانید چه چیزی اشتباه است، بلکه دلیل وقوع آن را نیز پیدا کنید.
تفاوت Observability و Monitoring
در حالی که Monitoring برای جمع‌آوری و مشاهده معیارهای از پیش تعریف‌شده (مثل استفاده از CPU یا تعداد درخواست‌ها) طراحی شده است، Observability بر قابلیت مشاهده و تحلیل داده‌های خام برای کشف الگوهای جدید تمرکز دارد. این مفهوم به تیم‌ها اجازه می‌دهد به جای پیش‌بینی همه سناریوها، در زمان وقوع مشکلات داده‌های لازم را جمع‌آوری و تحلیل کنند.
Video Link: https://youtu.be/UK71422S-rY
PlayList: https://www.youtube.com/playlist?list=PLJ9zDGwhhsBy6YIfteatuV50ezQODRsEQ
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
🔥10❤5🐳1
سوال:
یک جدول حجیم دارید و ۱۰ ایندکس روش دارید، یک رکورد اینسرت می‌کنید و «بلافاصله» همون رو کوئری میزنید که برگرده.
۱. آیا رکورد برمیگرده؟
۲.در دیتابیس های مختلف مثلا مای‌اس‌کیوال و پستگرس رفتار یک شکل است؟
۳. اگر درج و کوئیری در یک ترنزکشن اتفاق بیافتد رفتار متفاوت می‌شود؟
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
یک جدول حجیم دارید و ۱۰ ایندکس روش دارید، یک رکورد اینسرت می‌کنید و «بلافاصله» همون رو کوئری میزنید که برگرده.
۱. آیا رکورد برمیگرده؟
۲.در دیتابیس های مختلف مثلا مای‌اس‌کیوال و پستگرس رفتار یک شکل است؟
۳. اگر درج و کوئیری در یک ترنزکشن اتفاق بیافتد رفتار متفاوت می‌شود؟
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
🤔13👎1
در قسمت اول از پلی لیست Observability Engineering پیش از آنکه وارد مفاهیم اصلی شویم از طریق OpenTelemetry Demo Project سعی کردم یک Big Picture از آنچه قرار است به آن برسیم ارایه کنم. پروژه دمو اپن تلمتری یک پروژه ساده ولی خوش ساخت با استفاده از معماری میکرو سرویس است که الزامات مهم Observability در آن لحاظ شده است.
** یلدا مبارک :)
Video Link: https://youtu.be/s1YhTCYwbgs
PlayList: https://www.youtube.com/playlist?list=PLJ9zDGwhhsBy6YIfteatuV50ezQODRsEQ
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
** یلدا مبارک :)
Video Link: https://youtu.be/s1YhTCYwbgs
PlayList: https://www.youtube.com/playlist?list=PLJ9zDGwhhsBy6YIfteatuV50ezQODRsEQ
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
❤15👍1
اگر تجربه برنامه نویسی دارید و می‌خواید Go رو با جزییات بیشتری یاد بگیرید زمستان رو براش برنامه دارم. به دوستان خود بگویید :)
Playlist: https://youtube.com/playlist?list=PLJ9zDGwhhsBx6qqziDa4PoWUlKBw4rlBO&si=BdHSiIYnG1Cvkf09
Playlist: https://youtube.com/playlist?list=PLJ9zDGwhhsBx6qqziDa4PoWUlKBw4rlBO&si=BdHSiIYnG1Cvkf09
YouTube
آموزش GO
در این پلی لیست به بررسی مفاهیم زبان Go می پردازیم
❤31👍7
Microfrontend.ir
اگر تجربه برنامه نویسی دارید و می‌خواید Go رو با جزییات بیشتری یاد بگیرید زمستان رو براش برنامه دارم. به دوستان خود بگویید :) Playlist: https://youtube.com/playlist?list=PLJ9zDGwhhsBx6qqziDa4PoWUlKBw4rlBO&si=BdHSiIYnG1Cvkf09
در قسمت دهم از آموزش برنامه نویسی به زبان GO به بررسی و تعریف Performance از ابعاد مختلف و مستقل از زبان پرداختیم.
به جهان برنا‌مه‌نویسی پراگماتیک خوش آمدید. جایی که برنامه نویس ها از اهداف پرفورمنس نمی‌ترسند و تغییر در نیازمندی‌ها بدون ترس از افت پرفورمنس اتفاق می‌افتد و کدبیس ساده می‌ماند اما آیا این امکان پذیر است؟
برای داشتن بهینگی شما بایستی تمرکز را از سرعت و لیتنسی بردارید. بویژه در نرم‌افزارهای خاص منظوره سرعت مهم است اما در حاشیه. استفاده غیر بهینه از ریسورس سرعت را کاهش می دهد. و دسترسی به سرعت بالا با کد غیر بهینه هزینه‌ها را بالا می‌برد. براین اساس بایستی نگاه جنرال‌تری به پرفورمنس داشته باشیم به عبارتی تمرکز ما بر کارایی بیشتر از سرعت اجرا باشد. به یاد داشته باشید سرعت پرتابل نیست!
Link: https://youtu.be/ZOClH2BLRwE
PlayList: https://www.youtube.com/playlist?list=PLJ9zDGwhhsBx6qqziDa4PoWUlKBw4rlBO
〰️〰️〰️〰️〰️〰️
© | @microfrontend_ir
به جهان برنا‌مه‌نویسی پراگماتیک خوش آمدید. جایی که برنامه نویس ها از اهداف پرفورمنس نمی‌ترسند و تغییر در نیازمندی‌ها بدون ترس از افت پرفورمنس اتفاق می‌افتد و کدبیس ساده می‌ماند اما آیا این امکان پذیر است؟
برای داشتن بهینگی شما بایستی تمرکز را از سرعت و لیتنسی بردارید. بویژه در نرم‌افزارهای خاص منظوره سرعت مهم است اما در حاشیه. استفاده غیر بهینه از ریسورس سرعت را کاهش می دهد. و دسترسی به سرعت بالا با کد غیر بهینه هزینه‌ها را بالا می‌برد. براین اساس بایستی نگاه جنرال‌تری به پرفورمنس داشته باشیم به عبارتی تمرکز ما بر کارایی بیشتر از سرعت اجرا باشد. به یاد داشته باشید سرعت پرتابل نیست!
Link: https://youtu.be/ZOClH2BLRwE
PlayList: https://www.youtube.com/playlist?list=PLJ9zDGwhhsBx6qqziDa4PoWUlKBw4rlBO
〰️〰️〰️〰️〰️〰️
© | @microfrontend_ir
🔥14❤4👍2
Microfrontend.ir
در قسمت دهم از آموزش برنامه نویسی به زبان GO به بررسی و تعریف Performance از ابعاد مختلف و مستقل از زبان پرداختیم. به جهان برنا‌مه‌نویسی پراگماتیک خوش آمدید. جایی که برنامه نویس ها از اهداف پرفورمنس نمی‌ترسند و تغییر در نیازمندی‌ها بدون ترس از افت پرفورمنس…
در قسمت یازدهم از آموزش برنامه نویسی به زبان گو به بررسی روند و مراحل Go Compiler پرداختیم.
Link: https://youtu.be/WkKGAhD9DRY
PlayList: https://www.youtube.com/playlist?list=PLJ9zDGwhhsBx6qqziDa4PoWUlKBw4rlBO
〰️〰️〰️〰️〰️〰️
© | @microfrontend_ir
Link: https://youtu.be/WkKGAhD9DRY
PlayList: https://www.youtube.com/playlist?list=PLJ9zDGwhhsBx6qqziDa4PoWUlKBw4rlBO
〰️〰️〰️〰️〰️〰️
© | @microfrontend_ir
❤11👍1
Forwarded from Reza Jafari
WEF_Future_of_Jobs_Report_2025.pdf
14 MB
گزارش "Future of Jobs Report 2025" از World Economic Forum درباره آینده مشاغل در سال 2030
این گزارش 300 صفحه‌ای و طولانیه، ولی نکات مهمش رو می‌تونید تو ویدیو 1 دقیقه‌ای زیر ببینید.
@reza_jafari_ai
این گزارش 300 صفحه‌ای و طولانیه، ولی نکات مهمش رو می‌تونید تو ویدیو 1 دقیقه‌ای زیر ببینید.
@reza_jafari_ai
❤3
Forwarded from Go Casts 🚀
هفته نامه Golang Nugget رو اگه دوست داشتید دنبال کنید.
منابع خوبی رو معرفی میکنه
این یه نمونه ش هست
https://golangnugget.com/p/go-concurrency-upgrade-strategies-memory-management-january-6-2024
این خبرنامه رو آقا لیام عزیز مدیریت میکنه
https://x.com/liammanesh
@gocasts
منابع خوبی رو معرفی میکنه
این یه نمونه ش هست
https://golangnugget.com/p/go-concurrency-upgrade-strategies-memory-management-january-6-2024
این خبرنامه رو آقا لیام عزیز مدیریت میکنه
https://x.com/liammanesh
@gocasts
Golang Nugget
Golang Nugget - January 6, 2024
Go's concurrency, upgrade strategies, and internals of memory management. Plus, tools and tips for Gophers.
👍8
Forwarded from Azibom Channel (MohammadReza Shabani)
❤7👍3