Forwarded from AI Labdon
🤖 علاقه‌مند به دنیای هوش مصنوعی هستی؟
🏖 دنبال می‌کنی که چطور AI داره دنیا رو متحول می‌کنه؟
🍻پس جای درستی اومدی!
🎯 در کانال ما هر روز:
🔍 جدیدترین اخبار و دستاوردهای دنیای AI
🧠 تحلیل تخصصی در حوزه یادگیری ماشین، دیپ لرنینگ و مدل‌های زبانی
💼 بررسی کاربردهای هوش مصنوعی در پزشکی، صنعت، آموزش، امنیت و اقتصاد
🛠 معرفی ابزارها، دوره‌ها و منابع یادگیری
📈 بررسی ترندها و آینده فناوری‌های مرتبط با هوش مصنوعی
🍄همه‌ی این‌ها به زبان ساده، خلاصه و قابل فهم برای همه علاقه‌مندان — از مبتدی تا حرفه‌ای!
👇👇👇👇👇👇
https://t.iss.one/ai_labdon
🏖 دنبال می‌کنی که چطور AI داره دنیا رو متحول می‌کنه؟
🍻پس جای درستی اومدی!
🎯 در کانال ما هر روز:
🔍 جدیدترین اخبار و دستاوردهای دنیای AI
🧠 تحلیل تخصصی در حوزه یادگیری ماشین، دیپ لرنینگ و مدل‌های زبانی
💼 بررسی کاربردهای هوش مصنوعی در پزشکی، صنعت، آموزش، امنیت و اقتصاد
🛠 معرفی ابزارها، دوره‌ها و منابع یادگیری
📈 بررسی ترندها و آینده فناوری‌های مرتبط با هوش مصنوعی
🍄همه‌ی این‌ها به زبان ساده، خلاصه و قابل فهم برای همه علاقه‌مندان — از مبتدی تا حرفه‌ای!
👇👇👇👇👇👇
https://t.iss.one/ai_labdon
🎉1
🔵 عنوان مقاله
Container-Aware GOMAXPROCS
🟢 خلاصه مقاله:
** بلاگ رسمی Go سری تازه‌ای را درباره ویژگی‌های Go 1.25 آغاز کرده و در نخستین بخش، به رفتار آگاه از کانتینر در GOMAXPROCS می‌پردازد. مقدار پیش‌فرض این تنظیم روی سخت‌افزار واقعی منطقی است، اما در کانتینرها می‌تواند به‌دلیل محدودیت‌های CPU (مانند cgroup و quota) مشکل ایجاد کند. در Go 1.25 تشخیص و تنظیم پیش‌فرض بهبود یافته تا با محدودیت‌های کانتینر سازگارتر شود، عملکرد پیش‌بینی‌پذیرتری بدهد و تنها در برخی موارد نیاز به تنظیم دستی باقی بماند.
🟣لینک مقاله:
https://golangweekly.com/link/173329/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Container-Aware GOMAXPROCS
🟢 خلاصه مقاله:
** بلاگ رسمی Go سری تازه‌ای را درباره ویژگی‌های Go 1.25 آغاز کرده و در نخستین بخش، به رفتار آگاه از کانتینر در GOMAXPROCS می‌پردازد. مقدار پیش‌فرض این تنظیم روی سخت‌افزار واقعی منطقی است، اما در کانتینرها می‌تواند به‌دلیل محدودیت‌های CPU (مانند cgroup و quota) مشکل ایجاد کند. در Go 1.25 تشخیص و تنظیم پیش‌فرض بهبود یافته تا با محدودیت‌های کانتینر سازگارتر شود، عملکرد پیش‌بینی‌پذیرتری بدهد و تنها در برخی موارد نیاز به تنظیم دستی باقی بماند.
🟣لینک مقاله:
https://golangweekly.com/link/173329/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
go.dev
Container-aware GOMAXPROCS - The Go Programming Language
New GOMAXPROCS defaults in Go 1.25 improve behavior in containers.
🔥1
🔵 عنوان مقاله
How Go Schedules Millions of Goroutines: A Deep Dive into GMP
🟢 خلاصه مقاله:
این مطلب با نگاهی عمیق و قابل‌فهم توضیح می‌دهد که زمان‌بند Go چگونه با مدل GMP (گورو‌تین‌ها، رشته‌های سیستم‌عامل، و پردازنده‌های منطقی) میلیون‌ها گورو‌تین را روی تعداد کمی نخ اجرا میکند. سازوکار صف‌های اجرا، «کار‌ربایی» بین پردازنده‌ها، نحوهٔ ایجاد و توقف گورو‌تین‌ها، مدیریت بلاک‌شدن روی I/O یا syscall، پیش‌امپشن برای عدالت و کاهش تأخیر، و تعامل زمان‌بند با جمع‌آوری زباله بررسی میشود. همچنین نکات عملی مانند تنظیم GOMAXPROCS، پرهیز از انفجار گورو‌تین‌ها، مدیریت فشار کانال‌ها، و استفاده از ابزارهای ردیابی و pprof برای عیب‌یابی مطرح شده است. در کنار آن، دو راهنمای کاربردی معرفی میشود: ساخت تصویر کانتینر از کد Go با Depot API (تأکید بر بیلد سریع، کش و ادغام در CI) و استقرار یک سایت استاتیک Hugo روی Hetzнер (از آماده‌سازی تا TLS و تحویل پایدار). این مجموعه پلی بین تئوری زمان‌بندی و استقرار عملی ایجاد میکند.
🟣لینک مقاله:
https://golangweekly.com/link/173629/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
How Go Schedules Millions of Goroutines: A Deep Dive into GMP
🟢 خلاصه مقاله:
این مطلب با نگاهی عمیق و قابل‌فهم توضیح می‌دهد که زمان‌بند Go چگونه با مدل GMP (گورو‌تین‌ها، رشته‌های سیستم‌عامل، و پردازنده‌های منطقی) میلیون‌ها گورو‌تین را روی تعداد کمی نخ اجرا میکند. سازوکار صف‌های اجرا، «کار‌ربایی» بین پردازنده‌ها، نحوهٔ ایجاد و توقف گورو‌تین‌ها، مدیریت بلاک‌شدن روی I/O یا syscall، پیش‌امپشن برای عدالت و کاهش تأخیر، و تعامل زمان‌بند با جمع‌آوری زباله بررسی میشود. همچنین نکات عملی مانند تنظیم GOMAXPROCS، پرهیز از انفجار گورو‌تین‌ها، مدیریت فشار کانال‌ها، و استفاده از ابزارهای ردیابی و pprof برای عیب‌یابی مطرح شده است. در کنار آن، دو راهنمای کاربردی معرفی میشود: ساخت تصویر کانتینر از کد Go با Depot API (تأکید بر بیلد سریع، کش و ادغام در CI) و استقرار یک سایت استاتیک Hugo روی Hetzнер (از آماده‌سازی تا TLS و تحویل پایدار). این مجموعه پلی بین تئوری زمان‌بندی و استقرار عملی ایجاد میکند.
🟣لینک مقاله:
https://golangweekly.com/link/173629/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Medium
How Go Schedules Millions of Goroutines: A Deep Dive into GMP
How Go really handles concurrency. Demystifying the GMP scheduler to prevent performance pitfalls and write better code.
Forwarded from Software Engineer Labdon
دلیل اینکه در زبان‌هایی مثل Go یا Rust یا حتی C دچار سردرگمی میشید، بخاطر این هست که میخواهید ساختارهایی که از زبان‌های شی‌گرا در ذهن دارید رو دقیقا به همون شکل در این‌ها هم داشته باشید. این زبان‌ها هم تا حدی این توهم رو ایجاد میکنند که اینکار شدنی هست؛ و میتوان گفت که همینطور است، ولی فقط در ظاهر!
بسیاری از چیزهایی که شما در زبان‌های شی‌گرا با آن‌ها اشنا شدید، مختص و منحصر به شی‌گرایی نیستند. صرفا چون شما احتمالا به دلایل تاریخی برنامه‌نویسی رو با شی‌گرایی یاد گرفتید، ممکن هست اینطور تصور کنید که این مفاهیم فقط مختص به شی گرایی هستند. در حالی که بیشتر مفاهیمی که در ذهن دارید در هر پارادایم و هر زبانی قابل پیاده سازی هست.
مثلا اگر امروز به یک برنامه‌نویس Go یا Rust یک پروژه‌ی بانکی یا یک سیستم فروشگاه رو محول کنید، به احتمال زیاد این پروژه رو مبتنی بر DDD انجام خواهد داد! حتی یک برنامه‌نویس Clojure هم احتمالا همین رویه را دنبال خواهد کرد! الان احتمالا در ذهن شما این سوال پیش آمده که DDD؟ چطور همچین چیزی ممکن هست؟ مگه این برای شی گرایی نیست؟ خیر، «شما» اون رو با شی گرایی یاد گرفتید، ولی خودش یک ایده‌ی عمومی است.
شما به شکلی آموزش دیده‌اید که یونیت‌های کد را در قالب کلاس ها ببینید. و وقتی به زبان‌هایی میرسید که دارای کلاس نیستند، اولین چیزی که به فکرتان میرسد این است که کلاس را در آن‌ها شبیه سازی کنید. درست است؟
این دیدگاه، شما را دچار مشکل میکند، و دلیل اصلی اش این است که شما حتی در زبان‌های شی‌گرا هم به درستی درک نکرده بودید که کلاس چیست! و همان دیدگاه اشتباه خود درباره کلاس رو به سایر زبان‌ها هم انتقال میدهید!
وقتی حرف از کلاس میشود، بیشتر افراد میکنند کلاس یک بلاک از کد است که تعدادی فیلد و متد را بین دو {} گرد هم آورده است.
اما کسی سوال نمیکند خب چرا اینکار را کردند؟ فقط چون میخواستند یک سری فیلد داشته باشند و یک سری تابع بتوانند روی ان‌ها کار کنند؟
خب این رو که از قدیم در همه زبان‌ها داشتیم. مگر اصلا جور دیگری میشود برنامه نویسی کرد؟ در تمام زبان‌ها یک سری دیتا داریم و یک سری تابع که روی آن دیتا کار میکنند. قدیمی ترین کد C ای که میتوانید پیدا کنید را باز کنید، احتمالا در آن یک استراکت پیدا میکنید به همراه تعدادی تابع که روی آن استراکت کار میکنند. این رویه قبل از شی گرایی هم وجود داشته... فقط چون این دو را کنار هم درون {} قرار میدهید اسمش میشود کلاس؟ یعنی فقط چون میخواستند کنار هم باشن؟ که تنها نباشن؟ غصه نخورن؟ فکر نمیکنید شاید دلایل مهمتری برای این موضوع وجود داشته؟
ویژگی‌هایی وجود دارد که باعث میشود کلاس، کلاس بشود:
۱. کلاس دارای مکانیزم وراثت است.
۲. کلاس پلی مورفیسم مبتنی بر وراثت را فراهم میکند (متدهای virtual)
۳. از روی کلاس، میتوان آبجکتی در حافظه تولید کرد.
۴. کلاس آبجکت‌ها را دسته بندی میکند (برای همین اسمش class است). یعنی باید بتوان جواب این سوال را جویا شد: ایا فلان آبجکت جزو فلان کلاس است؟
۵. آبجکت‌های ساخته شده از روی کلاس، دارای لایف تایم متفاوتی از سایر بلاک ها هستند. ابجکت‌ها حالت رفرنس دارند. به این معنی که تقریبا در تمام زبان‌ها، در هیپ قرار میگیرند.
اینکه دیتا و توابع را کنار هم و در یک بلاک به اسم کلاس جمع کردن‌اند، به خاطر این است که یک کانتکست یکپارچه پدید آورند که در قالب آن بتوانند همه‌ی ویژگی‌های بالا را برآورده کنند.
اینکه شما یک استراکت بسازید، و چند تابع تعریف کنید که روی آن استراکت کار کنند، کدام یک از ویژگی‌های بالا را شامل میشود؟ این دو بخش لزومی هم ندارد که جدا از هم باشند. مثلا در zig میتوانید توابع را عین یک کلاس درون همان بلاک مربوط به استراکت قرار دهید. ولی باز هم در صورت انجام اینکار، تبدیل به کلاس نمیشود چون هیچکدام از ویژگی‌های بالا را ندارد.
یا مثلا در C یا سایر زبان‌ها، فیلدها و متدها را در ماژول‌ها گرد هم میاورند. ایا با اینکار آن ماژول تبدیل به کلاس شده است؟
اتفاقی که این وسط افتاده این است:
۱. شما در حین یادگیری شی گرایی بدرستی درک نکردید که کلاس چیست!
۲. بر مبنای آن درک اشتباه، فکر کردید شی گرایی یعنی کنار هم قرار دادن فیلدها و متدها در یک بلاک.
۳. اصرار به این دارید که این درک اشتباه را در زبان‌هایی که اصلا دارای کلاس نیستند پیاده سازی کنید.
این همان جایی است که در زبان‌هایی مانند Go و Rust و Zig و C سایرین به مشکل بر میخورید. برای همین هست که میگویند این‌ها را با زبان‌های شی گرا اشتباه نگیرید. چون این‌ها از نظر ظاهری، شاید شرایطی را فراهم کنند که به چشم شما مشابه چیزی باشد که در شی گرایی به یاد داشتید، ولی از نظر Semantics با زبان‌های شی گرا متفاوت اند.
| <Amirreza Gh/>
بسیاری از چیزهایی که شما در زبان‌های شی‌گرا با آن‌ها اشنا شدید، مختص و منحصر به شی‌گرایی نیستند. صرفا چون شما احتمالا به دلایل تاریخی برنامه‌نویسی رو با شی‌گرایی یاد گرفتید، ممکن هست اینطور تصور کنید که این مفاهیم فقط مختص به شی گرایی هستند. در حالی که بیشتر مفاهیمی که در ذهن دارید در هر پارادایم و هر زبانی قابل پیاده سازی هست.
مثلا اگر امروز به یک برنامه‌نویس Go یا Rust یک پروژه‌ی بانکی یا یک سیستم فروشگاه رو محول کنید، به احتمال زیاد این پروژه رو مبتنی بر DDD انجام خواهد داد! حتی یک برنامه‌نویس Clojure هم احتمالا همین رویه را دنبال خواهد کرد! الان احتمالا در ذهن شما این سوال پیش آمده که DDD؟ چطور همچین چیزی ممکن هست؟ مگه این برای شی گرایی نیست؟ خیر، «شما» اون رو با شی گرایی یاد گرفتید، ولی خودش یک ایده‌ی عمومی است.
شما به شکلی آموزش دیده‌اید که یونیت‌های کد را در قالب کلاس ها ببینید. و وقتی به زبان‌هایی میرسید که دارای کلاس نیستند، اولین چیزی که به فکرتان میرسد این است که کلاس را در آن‌ها شبیه سازی کنید. درست است؟
این دیدگاه، شما را دچار مشکل میکند، و دلیل اصلی اش این است که شما حتی در زبان‌های شی‌گرا هم به درستی درک نکرده بودید که کلاس چیست! و همان دیدگاه اشتباه خود درباره کلاس رو به سایر زبان‌ها هم انتقال میدهید!
وقتی حرف از کلاس میشود، بیشتر افراد میکنند کلاس یک بلاک از کد است که تعدادی فیلد و متد را بین دو {} گرد هم آورده است.
اما کسی سوال نمیکند خب چرا اینکار را کردند؟ فقط چون میخواستند یک سری فیلد داشته باشند و یک سری تابع بتوانند روی ان‌ها کار کنند؟
خب این رو که از قدیم در همه زبان‌ها داشتیم. مگر اصلا جور دیگری میشود برنامه نویسی کرد؟ در تمام زبان‌ها یک سری دیتا داریم و یک سری تابع که روی آن دیتا کار میکنند. قدیمی ترین کد C ای که میتوانید پیدا کنید را باز کنید، احتمالا در آن یک استراکت پیدا میکنید به همراه تعدادی تابع که روی آن استراکت کار میکنند. این رویه قبل از شی گرایی هم وجود داشته... فقط چون این دو را کنار هم درون {} قرار میدهید اسمش میشود کلاس؟ یعنی فقط چون میخواستند کنار هم باشن؟ که تنها نباشن؟ غصه نخورن؟ فکر نمیکنید شاید دلایل مهمتری برای این موضوع وجود داشته؟
ویژگی‌هایی وجود دارد که باعث میشود کلاس، کلاس بشود:
۱. کلاس دارای مکانیزم وراثت است.
۲. کلاس پلی مورفیسم مبتنی بر وراثت را فراهم میکند (متدهای virtual)
۳. از روی کلاس، میتوان آبجکتی در حافظه تولید کرد.
۴. کلاس آبجکت‌ها را دسته بندی میکند (برای همین اسمش class است). یعنی باید بتوان جواب این سوال را جویا شد: ایا فلان آبجکت جزو فلان کلاس است؟
۵. آبجکت‌های ساخته شده از روی کلاس، دارای لایف تایم متفاوتی از سایر بلاک ها هستند. ابجکت‌ها حالت رفرنس دارند. به این معنی که تقریبا در تمام زبان‌ها، در هیپ قرار میگیرند.
اینکه دیتا و توابع را کنار هم و در یک بلاک به اسم کلاس جمع کردن‌اند، به خاطر این است که یک کانتکست یکپارچه پدید آورند که در قالب آن بتوانند همه‌ی ویژگی‌های بالا را برآورده کنند.
اینکه شما یک استراکت بسازید، و چند تابع تعریف کنید که روی آن استراکت کار کنند، کدام یک از ویژگی‌های بالا را شامل میشود؟ این دو بخش لزومی هم ندارد که جدا از هم باشند. مثلا در zig میتوانید توابع را عین یک کلاس درون همان بلاک مربوط به استراکت قرار دهید. ولی باز هم در صورت انجام اینکار، تبدیل به کلاس نمیشود چون هیچکدام از ویژگی‌های بالا را ندارد.
یا مثلا در C یا سایر زبان‌ها، فیلدها و متدها را در ماژول‌ها گرد هم میاورند. ایا با اینکار آن ماژول تبدیل به کلاس شده است؟
اتفاقی که این وسط افتاده این است:
۱. شما در حین یادگیری شی گرایی بدرستی درک نکردید که کلاس چیست!
۲. بر مبنای آن درک اشتباه، فکر کردید شی گرایی یعنی کنار هم قرار دادن فیلدها و متدها در یک بلاک.
۳. اصرار به این دارید که این درک اشتباه را در زبان‌هایی که اصلا دارای کلاس نیستند پیاده سازی کنید.
این همان جایی است که در زبان‌هایی مانند Go و Rust و Zig و C سایرین به مشکل بر میخورید. برای همین هست که میگویند این‌ها را با زبان‌های شی گرا اشتباه نگیرید. چون این‌ها از نظر ظاهری، شاید شرایطی را فراهم کنند که به چشم شما مشابه چیزی باشد که در شی گرایی به یاد داشتید، ولی از نظر Semantics با زبان‌های شی گرا متفاوت اند.
| <Amirreza Gh/>
👍6💯2
🔵 عنوان مقاله
A-go-ha! Gopher Hawaiian Shirt Patterns
🟢 خلاصه مقاله:
**
در اواخر تابستان، خبر جالبی برای جامعهٔ Go منتشر شده است: در سال ۲۰۲۳ راس کاکس همراه با رنه فرنچ، خالق ماسکات گوفر، پیراهن‌های هاوایی با طرح‌های مرتبط با Go طراحی و چاپ کردند. اکنون الگوهای این طرح‌ها در چند رنگ به‌طور عمومی در دسترس قرار گرفته‌اند تا علاقه‌مندان بتوانند نسخه‌های خودشان را تهیه یا از آن‌ها استفاده خلاقانه کنند. این یک حرکت سرگرم‌کننده و نمادین از فرهنگ جامعهٔ Go است که حال‌وهوای برنامه‌نویسی را با استایل تابستانی پیوند می‌دهد.
🟣لینک مقاله:
https://golangweekly.com/link/173619/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
A-go-ha! Gopher Hawaiian Shirt Patterns
🟢 خلاصه مقاله:
**
در اواخر تابستان، خبر جالبی برای جامعهٔ Go منتشر شده است: در سال ۲۰۲۳ راس کاکس همراه با رنه فرنچ، خالق ماسکات گوفر، پیراهن‌های هاوایی با طرح‌های مرتبط با Go طراحی و چاپ کردند. اکنون الگوهای این طرح‌ها در چند رنگ به‌طور عمومی در دسترس قرار گرفته‌اند تا علاقه‌مندان بتوانند نسخه‌های خودشان را تهیه یا از آن‌ها استفاده خلاقانه کنند. این یک حرکت سرگرم‌کننده و نمادین از فرهنگ جامعهٔ Go است که حال‌وهوای برنامه‌نویسی را با استایل تابستانی پیوند می‌دهد.
🟣لینک مقاله:
https://golangweekly.com/link/173619/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
GitHub
GitHub - rsc/gophershirt: Gopher Hawaiian Shirts
Gopher Hawaiian Shirts. Contribute to rsc/gophershirt development by creating an account on GitHub.
🔵 عنوان مقاله
now supports Go 1.25.
🟢 خلاصه مقاله:
اکنون این پروژه به‌طور کامل از Go 1.25 پشتیبانی میکند؛ خبری که در آخرین شماره Golang Weekly برجسته شده است. این پشتیبانی شامل ساخت و آزمایش با ابزارهای Go 1.25، همسان‌سازی CI و تصاویر کانتینری، و به‌روزرسانی اسناد است تا ارتقاء بدون اصطکاک انجام شود. با توجه به بهبودهای کارایی، پایداری و ابزارها در Go 1.25، توصیه میشود Go را ارتقاء دهید، go.mod را به 1.25 تنظیم کنید، go mod tidy اجرا کنید و تست‌ها را بگذرانید؛ در صورت بروز مشکل، آن را گزارش کنید. اگر فعلاً ارتقاء نمی‌دهید، میتوانید از نسخه فعلی خود استفاده کنید، اما ویژگی‌های جدید پروژه احتمالاً بر پایه Go 1.25 ارائه خواهند شد.
🟣لینک مقاله:
https://golangweekly.com/link/173624/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
now supports Go 1.25.
🟢 خلاصه مقاله:
اکنون این پروژه به‌طور کامل از Go 1.25 پشتیبانی میکند؛ خبری که در آخرین شماره Golang Weekly برجسته شده است. این پشتیبانی شامل ساخت و آزمایش با ابزارهای Go 1.25، همسان‌سازی CI و تصاویر کانتینری، و به‌روزرسانی اسناد است تا ارتقاء بدون اصطکاک انجام شود. با توجه به بهبودهای کارایی، پایداری و ابزارها در Go 1.25، توصیه میشود Go را ارتقاء دهید، go.mod را به 1.25 تنظیم کنید، go mod tidy اجرا کنید و تست‌ها را بگذرانید؛ در صورت بروز مشکل، آن را گزارش کنید. اگر فعلاً ارتقاء نمی‌دهید، میتوانید از نسخه فعلی خود استفاده کنید، اما ویژگی‌های جدید پروژه احتمالاً بر پایه Go 1.25 ارائه خواهند شد.
🟣لینک مقاله:
https://golangweekly.com/link/173624/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
The GitHub Blog
CodeQL 2.22.4 adds support for Go 1.25 and accuracy improvements - GitHub Changelog
CodeQL is the static analysis engine behind GitHub code scanning, which finds and remediates security issues in your code. We’ve recently released CodeQL 2.22.4, which adds support for Go 1.25,…
🤝1
🚀 به کانال تخصصی انواع دیتابیس و دیتا خوش اومدی!
اینجا هر روز مطالب کاربردی و به‌روز درباره موضوعات زیر می‌ذاریم:
🔹 PostgreSQL
🔹 RDBMS (سیستم‌های مدیریت پایگاه داده رابطه‌ای)
🔹 NoSQL
🔹 Big Data
🔹 Data Science
🔹 Data Engineering
📚 یادگیری، نکات حرفه‌ای و تازه‌ترین ترندهای دنیای دیتا همه اینجاست!
📌 همین حالا جوین شو و یک قدم جلوتر باش
https://t.iss.one/Database_Academy
اینجا هر روز مطالب کاربردی و به‌روز درباره موضوعات زیر می‌ذاریم:
🔹 PostgreSQL
🔹 RDBMS (سیستم‌های مدیریت پایگاه داده رابطه‌ای)
🔹 NoSQL
🔹 Big Data
🔹 Data Science
🔹 Data Engineering
📚 یادگیری، نکات حرفه‌ای و تازه‌ترین ترندهای دنیای دیتا همه اینجاست!
📌 همین حالا جوین شو و یک قدم جلوتر باش
https://t.iss.one/Database_Academy