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🤝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
❤1
🔵 عنوان مقاله
D2: A Declarative Diagramming Tool in Go
🟢 خلاصه مقاله:
D2 یک ابزار نمودارسازی اعلان‌محور و متن‌محور است که با زبان Go ساخته شده و از نظر رویکرد شبیه Mermaid عمل میکند؛ یعنی به‌جای رسم دستی، با نوشتن متن، نمودار تولید میکنید. به‌روزرسانی اخیر خروجی ASCII را اضافه کرده تا بتوان همان نمودارها را به‌صورت متن ساده در ترمینال، READMEها، ایمیل‌ها و محیط‌های محدود به متن استفاده کرد. این قابلیت، کاربردپذیری و دسترس‌پذیری D2 را در جریان‌های کاری مختلف افزایش می‌دهد.
🟣لینک مقاله:
https://golangweekly.com/link/173083/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
D2: A Declarative Diagramming Tool in Go
🟢 خلاصه مقاله:
D2 یک ابزار نمودارسازی اعلان‌محور و متن‌محور است که با زبان Go ساخته شده و از نظر رویکرد شبیه Mermaid عمل میکند؛ یعنی به‌جای رسم دستی، با نوشتن متن، نمودار تولید میکنید. به‌روزرسانی اخیر خروجی ASCII را اضافه کرده تا بتوان همان نمودارها را به‌صورت متن ساده در ترمینال، READMEها، ایمیل‌ها و محیط‌های محدود به متن استفاده کرد. این قابلیت، کاربردپذیری و دسترس‌پذیری D2 را در جریان‌های کاری مختلف افزایش می‌دهد.
🟣لینک مقاله:
https://golangweekly.com/link/173083/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
D2 Documentation
Home | D2 Documentation
D2 is a modern DSL that turns text to diagrams.
❤2
Forwarded from AI Labdon
علی‌بابا بمب هوش مصنوعی را ترکاند | «3-Qwen» با یک تریلیون پارامتر، تهدیدی جدی برای GPT و گوگل!
https://saednews.com/c/10169/495846
https://saednews.com/c/10169/495846
Saednews
علی‌بابا بمب هوش مصنوعی را ترکاند | «3-Qwen» با یک تریلیون پارامتر، تهدیدی جدی برای GPT و گوگل!
ساعدنیوز: علی‌بابا با معرفی مدل هوش مصنوعی جدیدش، رقابت را برای غول‌های جهانی فناوری داغ‌تر کرد.
❤3🏆1
🔵 عنوان مقاله
Ergo 3.1: An Actor-Based Framework for Go
🟢 خلاصه مقاله:
Ergo 3.1 یک فریم‌ورک بازیگرمحور برای زبان Go است که الگوها و مفاهیم آزموده‌شدهٔ دنیای Erlang/OTP—مانند بازیگرهای ایزوله با ارتباط پیام‌محور و الگوهای نظارت و بازیابی—را به Go می‌آورد. این رویکرد با جداسازی خطاها، مدیریت ساخت‌یافتهٔ هم‌زمانی و پشتیبانی از سناریوهای توزیع‌شده، ساخت سرویس‌های مقیاس‌پذیر و مقاوم را ساده‌تر میکند. نسخهٔ 3.1 در مسیر پایداری، کارایی و سادگی API در سری v3 پیش رفته و ابزارهای آشنا و کارآمدی برای طراحی سیستم‌های مقاوم در اکوسیستم Go فراهم میکند.
🟣لینک مقاله:
https://golangweekly.com/link/174078/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Ergo 3.1: An Actor-Based Framework for Go
🟢 خلاصه مقاله:
Ergo 3.1 یک فریم‌ورک بازیگرمحور برای زبان Go است که الگوها و مفاهیم آزموده‌شدهٔ دنیای Erlang/OTP—مانند بازیگرهای ایزوله با ارتباط پیام‌محور و الگوهای نظارت و بازیابی—را به Go می‌آورد. این رویکرد با جداسازی خطاها، مدیریت ساخت‌یافتهٔ هم‌زمانی و پشتیبانی از سناریوهای توزیع‌شده، ساخت سرویس‌های مقیاس‌پذیر و مقاوم را ساده‌تر میکند. نسخهٔ 3.1 در مسیر پایداری، کارایی و سادگی API در سری v3 پیش رفته و ابزارهای آشنا و کارآمدی برای طراحی سیستم‌های مقاوم در اکوسیستم Go فراهم میکند.
🟣لینک مقاله:
https://golangweekly.com/link/174078/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
GitHub
GitHub - ergo-services/ergo: An actor-based Framework with network transparency for creating event-driven architecture in Golang.…
An actor-based Framework with network transparency for creating event-driven architecture in Golang. Inspired by Erlang. Zero dependencies. - GitHub - ergo-services/ergo: An actor-based Framework ...
❤2
🔵 عنوان مقاله
Let's Look at Go's New Experimental API for JSON
🟢 خلاصه مقاله:
**این مطلب نگاهی عملی به یک API آزمایشی و جدید برای JSON در Go 1.25 دارد؛ تلاشی که به‌دلیل کاستی‌های بسته قدیمی json شکل گرفته است. مقاله توضیح می‌دهد این نسخه «v2» چه مشکلاتی از طراحی قبلی را هدف گرفته، تجربه برنامه‌نویس را چگونه شفاف‌تر و قابل پیش‌بینی‌تر میکند، و در کارهای روزمره مثل encode/decode، پیکربندی رفتار، مدیریت خطا و رسیدگی به مواردی مانند اعداد، null، فیلدهای ساختار و جریان‌ها چه تفاوت‌هایی دارد. همچنین تأکید میکند که این API هنوز آزمایشی است، برای ارزیابی و دریافت بازخورد عرضه شده، ممکن است تغییر کند، و توصیه‌هایی برای نحوه امتحان‌کردن آن در Go 1.25 و ملاحظات مهاجرت ارائه میکند.
🟣لینک مقاله:
https://golangweekly.com/link/174056/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Let's Look at Go's New Experimental API for JSON
🟢 خلاصه مقاله:
**این مطلب نگاهی عملی به یک API آزمایشی و جدید برای JSON در Go 1.25 دارد؛ تلاشی که به‌دلیل کاستی‌های بسته قدیمی json شکل گرفته است. مقاله توضیح می‌دهد این نسخه «v2» چه مشکلاتی از طراحی قبلی را هدف گرفته، تجربه برنامه‌نویس را چگونه شفاف‌تر و قابل پیش‌بینی‌تر میکند، و در کارهای روزمره مثل encode/decode، پیکربندی رفتار، مدیریت خطا و رسیدگی به مواردی مانند اعداد، null، فیلدهای ساختار و جریان‌ها چه تفاوت‌هایی دارد. همچنین تأکید میکند که این API هنوز آزمایشی است، برای ارزیابی و دریافت بازخورد عرضه شده، ممکن است تغییر کند، و توصیه‌هایی برای نحوه امتحان‌کردن آن در Go 1.25 و ملاحظات مهاجرت ارائه میکند.
🟣لینک مقاله:
https://golangweekly.com/link/174056/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
go.dev
A new experimental Go API for JSON - The Go Programming Language
Go 1.25 introduces experimental support for encoding/json/jsontext and encoding/json/v2 packages.
❤1
🔵 عنوان مقاله
The 9 Go Test Assertions I Use (and Why)
🟢 خلاصه مقاله:
**
الکس در ادامه‌ی بحث پرهیز از پکیج‌های آماده‌ی assertion در تست‌های Go، توضیح می‌دهد عملاً از چه چیزی استفاده میکند: مجموعه‌ای کم‌تعداد از ۹ تابع assertion دست‌ساز. او می‌گوید کتابخانه‌های بزرگ هرچند کدنویسی را کوتاه میکنند، اما اغلب منجر به ابهام، جریان کنترل پنهان و پیام‌های خطای نامفهوم می‌شوند. در مقابل، چند کمک‌تابع ساده که به t.Helper() متکی‌اند، بدون وابستگی خارجی و با پیام‌های خطای دقیق، هم خوانایی را بالا می‌برند و هم از تکرار جلوگیری میکنند.
این ۹ تابع رایج‌ترین نیازها را پوشش می‌دهند: برابری/نابرابری، nil و non-nil، شرایط بولی، شامل‌بودن در رشته‌ها یا مجموعه‌ها، و انتظارهای مرتبط با خطا. اصل مهم این است که این توابع نازک و شفاف باشند، منطق تست را پنهان نکنند و خطا را با مقادیر واقعی/مورد انتظار گزارش کنند.
او به دام‌های رایج نیز اشاره میکند: تفاوت nil در اینترفیس‌ها، محدودیت‌های مقایسه‌ی عمیق، و ترجیح سنجش رفتار قابل مشاهده به‌جای برابری کامل ساختارها. نتیجه‌گیری او درباره‌ی «آیا assertion ضدالگو است؟» مشروط است: اگر کلی‌گرا و جادویی شوند، بله؛ اما اگر کم‌حجم، صریح و متناسب با حوزه‌ی تست بمانند، ابزاری مفید هستند. قاعده نهایی: جایی که تکرار دارید از کمک‌تابع استفاده کنید، و هر جا یک بررسی اختصاصی پیام را شفاف‌تر میکند، همان را درجا بنویسید.
🟣لینک مقاله:
https://golangweekly.com/link/173627/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
The 9 Go Test Assertions I Use (and Why)
🟢 خلاصه مقاله:
**
الکس در ادامه‌ی بحث پرهیز از پکیج‌های آماده‌ی assertion در تست‌های Go، توضیح می‌دهد عملاً از چه چیزی استفاده میکند: مجموعه‌ای کم‌تعداد از ۹ تابع assertion دست‌ساز. او می‌گوید کتابخانه‌های بزرگ هرچند کدنویسی را کوتاه میکنند، اما اغلب منجر به ابهام، جریان کنترل پنهان و پیام‌های خطای نامفهوم می‌شوند. در مقابل، چند کمک‌تابع ساده که به t.Helper() متکی‌اند، بدون وابستگی خارجی و با پیام‌های خطای دقیق، هم خوانایی را بالا می‌برند و هم از تکرار جلوگیری میکنند.
این ۹ تابع رایج‌ترین نیازها را پوشش می‌دهند: برابری/نابرابری، nil و non-nil، شرایط بولی، شامل‌بودن در رشته‌ها یا مجموعه‌ها، و انتظارهای مرتبط با خطا. اصل مهم این است که این توابع نازک و شفاف باشند، منطق تست را پنهان نکنند و خطا را با مقادیر واقعی/مورد انتظار گزارش کنند.
او به دام‌های رایج نیز اشاره میکند: تفاوت nil در اینترفیس‌ها، محدودیت‌های مقایسه‌ی عمیق، و ترجیح سنجش رفتار قابل مشاهده به‌جای برابری کامل ساختارها. نتیجه‌گیری او درباره‌ی «آیا assertion ضدالگو است؟» مشروط است: اگر کلی‌گرا و جادویی شوند، بله؛ اما اگر کم‌حجم، صریح و متناسب با حوزه‌ی تست بمانند، ابزاری مفید هستند. قاعده نهایی: جایی که تکرار دارید از کمک‌تابع استفاده کنید، و هر جا یک بررسی اختصاصی پیام را شفاف‌تر میکند، همان را درجا بنویسید.
🟣لینک مقاله:
https://golangweekly.com/link/173627/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
www.alexedwards.net
The 9 Go test assertions I use (and why) - Alex Edwards
👍1