🍾حدیث روز
➖➖➖➖➖➖➖➖
🕸 @labdon_academy

🔵 عنوان مقاله
What's in an (Alias) Name?

🟢 خلاصه مقاله:
مقاله مذکور به موضوع اضافه شدن انواع نام‌های مستعار عمومی (Generic alias types) به زبان برنامه‌نویسی Go در نسخه 1.24، که انتظار می‌رود در فوریه 2025 منتشر شود، می‌پردازد. این ویژگی جدید بر پایه نام‌های مستعار موجود و جنریک‌ها (generics) ساخته شده است. یکی از مهم‌ترین کاربردهای نام‌های مستعار توانایی بازسازی کد بدون از بین بردن سازگاری با نسخه‌های قبلی است. رابرت در این مقاله به توضیح مفهوم نام‌های مستعار و دلایلی که گنجاندن آن‌ها در جنریک‌ها کار بیشتری را می‌طلبد پرداخته است. گسترش نام‌های مستعار به جنریک‌ها قابلیت‌های زبان برنامه‌نویسی Go را تقویت می‌کند و امکان ارتقاء کد را فراهم می‌آورد، در حالی که حفظ سازگاری و قابل استفاده بودن در پروژه‌های موجود را تضمین می‌کند.

🟣لینک مقاله:
https://golangweekly.com/link/160148/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Revive 1.4: A Faster, Configurable, Flexible Linter for Go

🟢 خلاصه مقاله:
این مقاله درباره ابزاری به نام "golint"، یک ابزار استاندارد برای تجزیه و تحلیل کد در زبان برنامه‌نویسی Go است که بحثی برای جایگزینی آن با نسخه بهبود یافته‌ای انجام شده است. جایگزین پیشنهادی قصد دارد ساختار، امکان پیکربندی و عملکرد بهتری نسبت به نسخه اصلی ارائه دهد. این ابزار جدید توسط بسیاری از پروژه‌ها و کتابخانه‌های بزرگ Go مورد استفاده قرار گرفته و در مخزنی در GitHub قابل دسترسی است. این تغییر از نسخه اصلی golint به نسخه جدید، بر اساس نیازهای کاربرانی که به دنبال افزایش بازده و قابلیت‌های بیشتر هستند، انجام شده است. این ابزار جدید به کاربران امکان می‌دهد تا با استفاده از گزینه‌های پیکربندی دقیق‌تر، کنترل بیشتری بر تجزیه و تحلیل کد خود داشته باشند.

🟣لینک مقاله:
https://golangweekly.com/link/160160/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

😱اینم یه چک لیست امنیتی برای api که توسعه میدید
گزینه خوبیه

https://roadmap.sh/best-practices/api-security

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Sets in Go: Using Maps and Recommended Packages

🟢 خلاصه مقاله:
معرفی خلاصه‌ای از مقاله‌ای در مورد ایجاد مجموعه‌ها در زبان برنامه‌نویسی Go است. این مقاله بر این تاکید دارد که زبان Go به طور بومی نوع داده‌ای برای مجموعه‌ها ندارد، اما می‌توان با استفاده از نقشه‌ها (maps) یک مجموعه را پیاده‌سازی کرد. همچنین، بسته‌هایی مانند golang-set وجود دارند که این پروسه را ساده‌تر می‌کنند. نویسنده مقاله، Willem، روش‌های کار با این ابزارها را نشان می‌دهد و چگونگی استفاده از نقشه‌ها برای ایجاد داده‌های مجموعه‌ای به طور کارآمد را توضیح می‌دهد. این بینش می‌تواند برای برنامه‌نویسانی که در حال کار با Go هستند و نیاز به مدیریت مجموعه های داده‌ای بدون تکرار دارند، مفید باشد.

🟣لینک مقاله:
https://golangweekly.com/link/160150/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Using Structs for Generic Argument Lists

🟢 خلاصه مقاله:
در این مقاله، یک الگوریتم جدید با یک الگوریتم قدیمی مقایسه می‌شود تا اطمینان حاصل شود که هر دو پاسخ یکسانی به دست می‌دهند. این مقایسه به منظور آزمایش بازنویسی‌ها و بهینه‌سازی‌های کد انجام می‌گیرد. استفاده از ساختارهای داده‌ای (structs) به همراه generics (کلیات) در زبان‌های برنامه‌نویسی کمک می‌کند تا کد نوشته شده ساده‌تر و مدیریت‌پذیرتر باشد. برای این منظور، نویسنده توضیح می‌دهد که چگونه می‌توان با استفاده از "پرچم‌های ویژه" مخصوص آزمایش، اطمینان حاصل کرد که تغییرات جدید در کد، کارآیی الگوریتم‌ها را به خطر نمی‌اندازد. فرآیند مقایسه الگوریتم‌ها به صورت موازی و گاهی اوقات به صورت تدریجی آزمایش و پیاده‌سازی می‌شود تا به تدریج جایگزین الگوریتم‌های قدیمی‌تر شود، بدون اینکه به سیستم جاری آسیب برساند.

🟣لینک مقاله:
https://www.emoses.org/posts/reusable-patterns-in-go/

➖➖➖➖➖➖➖➖
👑 @gopher_academy

کارکردن با افرادی که ...

➖➖➖➖➖➖➖➖
🕸 @labdon_academy

در بحث بهینه‌سازی بین دو تعریف زیر در Go:

var x *[]user  
// اشاره‌گر به یک slice از نوع user

var y []*user  
// یک slice از اشاره‌گرها به user

انتخاب بین این دو به نیاز و سناریوی خاصی که در برنامه‌تان دارید بستگی دارد. اما از دیدگاه بهینه‌سازی و کارایی، در اکثر موارد استفاده از y []*user بهینه‌تر است. دلایل این انتخاب را در ادامه توضیح می‌دهم.

### 1. تفاوت در حافظه و سربار (Memory Overhead):

ا- x *[]user (اشاره‌گر به slice از user):
ا  - x فقط یک اشاره‌گر به یک slice است، بنابراین شما باید یک ساختار slice کامل در جای دیگری از حافظه داشته باشید. این یعنی دو مرتبه نگهداری اطلاعات در حافظه:

    1. اشاره‌گر x که به یک slice اشاره می‌کند.

    2. خود ساختار slice که شامل اطلاعاتی مثل طول (length)، ظرفیت (capacity) و اشاره‌گر به آرایه پشتیبان (underlying array) است.

  - از طرفی، در صورتی که داده‌ها را تغییر دهید (مثلاً به slice مقدار جدیدی اضافه کنید)، باید در حافظه دوباره مقداردهی شود و سربار اضافی در مدیریت حافظه ایجاد می‌شود.

ا- y []*user (slice از اشاره‌گرها به user):
  ا- y یک slice از اشاره‌گرهاست و هر خانه آن فقط یک اشاره‌گر به یک user است. در اینجا شما فقط اشاره‌گرها را ذخیره می‌کنید و از فضای کمتری برای نگهداری هر عنصر استفاده می‌شود.

  - در واقع، داده‌ها از طریق اشاره‌گرها به مکان دیگری از حافظه اشاره دارند، که این بهینه‌تر است اگر شما قرار نیست ساختارهای user را مکرراً کپی کنید.

  - هر بار که یک عنصر به این slice اضافه کنید، تنها یک اشاره‌گر اضافه می‌شود و سربار اضافی برای کپی‌کردن ساختارهای بزرگ user وجود ندارد.

### 2. سهولت استفاده و تغییرپذیری:

- x *[]user:
  - برای هر بار دسترسی یا تغییر مقدار داخل x، باید ابتدا اشاره‌گر x را dereference کنید. این کار پیچیدگی کد را افزایش می‌دهد و نیازمند دستورات اضافی است.

  - مدیریت حافظه می‌تواند پیچیده‌تر باشد، به‌ویژه اگر در کدتان جابجایی یا تغییرات زیادی در slice رخ دهد.

- y []*user:
  - استفاده از y ساده‌تر است زیرا مستقیماً با یک slice سروکار دارید و نیازی به dereference نیست.

  - کار با اشاره‌گرها در Go معمولاً کارآمدتر است و نیاز به جابجایی و کپی داده‌ها کمتر است.

### 3. کارایی در عمل (Performance):

- x *[]user:
  - در این حالت هر بار که داده‌ها به slice اضافه یا تغییر داده شوند، اگر ظرفیت slice پر شده باشد، ممکن است نیاز به تخصیص حافظه جدید و کپی داده‌ها به مکان جدید باشد. این می‌تواند عملکرد را تحت تأثیر قرار دهد.

  - همچنین، داشتن اشاره‌گر اضافی ممکن است باعث افزایش سربار در حافظه و زمان دسترسی شود.

- y []*user:
  - بهینه‌تر است چون شما مستقیماً اشاره‌گرها به ساختارهای user را در slice ذخیره می‌کنید. هیچ نیازی به کپی‌کردن کل ساختار user نیست.
  - این روش کارایی بالاتری دارد، به‌ویژه زمانی که ساختار user بزرگ باشد و کپی‌کردن آن هزینه‌بر باشد.

### نتیجه‌گیری:
در بیشتر سناریوها، y []*user بهینه‌تر است:
- کمتر بودن سربار حافظه: به جای کپی‌کردن داده‌های بزرگ، تنها اشاره‌گرها را در slice نگه می‌دارید.
- عملکرد بهتر در تغییرات slice: تغییر دادن و مدیریت اشاره‌گرها سریع‌تر است و سربار کمتری در مقایسه با کپی کردن ساختارهای بزرگ دارد.

- سادگی و سهولت استفاده:
y []*user نیازی به dereference اضافی ندارد و مدیریت آن راحت‌تر است.

با این حال، اگر نیاز خاصی دارید که به یک اشاره‌گر به یک slice نیاز باشد، مانند مواقعی که می‌خواهید یک ساختار slice را بین چندین تابع به اشتراک بگذارید و آن را تغییر دهید، استفاده از x *[]user ممکن است مفید باشد.

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
The Hookdeck Event Gateway

🟢 خلاصه مقاله:
مقاله به بررسی یک صف بدون سرور می‌پردازد که برای ارسال، دریافت، تغییر دادن، فیلتر کردن و هدایت رویدادها در معماری مبتنی بر رویداد طراحی شده است. این سیستم امکان مدیریت انعطاف‌پذیر و مقیاس‌پذیر رویدادها را فراهم می‌آورد و به کاربران اجازه می‌دهد تا بدون نیاز به نگرانی درباره زیرساخت‌های سرور یا مدیریت آنها، روی منطق و جریان کاری تمرکز کنند. این فناوری برای محیط‌هایی که نیاز به پردازش حجم بالایی از رویدادها به صورت خودکار و در زمان واقعی دارند، بسیار مناسب است. در نهایت، استفاده از صف‌های بدون سرور می‌تواند به بهبود کارایی و کاهش هزینه‌های عملیاتی منجر شود، چرا که کاهش پیچیدگی مدیریتی و نیازهای سخت‌افزاری را به دنبال دارد.

🟣لینک مقاله:
https://hookdeck.com?ref=goweekly-506

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Logdy: A Web-Based Viewer for Logs

🟢 خلاصه مقاله:
مقاله‌ای که به بحث گذاشته شده، درباره ابزاری وب‌بنیان برای مشاهده لاگ‌ها در زمان واقعی است. این ابزار امکان استریم محتوا به یک رابط کاربری وب را با فیلترهایی که به‌طور خودکار تولید می‌شوند، فراهم می‌آورد. همچنین، این سیستم قابلیت تجزیه و تحلیل هر نوع فرمتی با استفاده از زبان برنامه‌نویسی TypeScript را دارد. در بخش دیگری از مقاله، به یک نمونه زنده اشاره شده که نشان‌دهنده قابلیت‌ها و کارایی این ابزار در شرایط واقعی است. این مقاله به ویژه برای توسعه‌دهندگان وب و مدیران سیستم‌های اطلاعاتی که به دنبال راهکارهایی برای مدیریت و تحلیل لاگ‌ها در زمان واقعی هستند، مفید است.

🟣لینک مقاله:
https://logdy.dev/

➖➖➖➖➖➖➖➖
👑 @gopher_academy

Elon Musk

➖➖➖➖➖➖➖➖
🕸 @labdon_academy

🔵گاهی اوقات توی go.mod شما یه سری کتابخونه نصب میکنید و جلوش ورژن رو میزنه 🤔اما بعضی ورژن به صورت زیر
v3.16.13-20221017192402-261537637ce8

اینجا توضیح دادیم که هر کدومش یعنی چی👇👇👇👇


این نوع نسخه زمانی استفاده می‌شود که یک تگ نسخه معتبر (مثل v1.2.3) وجود نداشته باشد و به جای آن از یک commit خاص در تاریخ معین استفاده شود.
این نسخه به شکل زیر ساختاردهی شده است:

v3.16.13-20221017192402-261537637ce8

### تحلیل اجزای نسخه:

1. v3.16.13:
   - این بخش نشان می‌دهد که نسخه پایه‌ای که بر اساس آن این pseudo-version ساخته شده، v3.16.13 است. این نشان می‌دهد که این commit بعد از این نسخه ساخته شده است.

2. 20221017192402:
   - این بخش نشان‌دهنده تاریخ و زمان commit است که به فرمت YYYYMMDDHHMMSS بیان می‌شود:
     - 2022: سال
     - 10: ماه
     - 17: روز
     - 19: ساعت (بر اساس 24 ساعت)
     - 24: دقیقه
     - 02: ثانیه
   - این به این معناست که commit مربوطه در تاریخ 17 اکتبر 2022 در ساعت 19:24:02 انجام شده است.

3. 261537637ce8:
   - این بخش کوتاهی از هش commit است که این pseudo-version به آن اشاره می‌کند. هش کامل commit در سیستم‌های مدیریت نسخه مثل Git معمولاً طولانی‌تر است، اما در اینجا تنها چند کاراکتر اول آن استفاده شده است.

### مفهوم کلی:
این نسخه (pseudo-version) نشان می‌دهد که یک commit خاص (با هش 261537637ce8) که پس از نسخه v3.16.13 ایجاد شده و در تاریخ 17 اکتبر 2022 ثبت شده، به عنوان نسخه استفاده می‌شود. این نوع نسخه معمولاً زمانی به کار می‌رود که توسعه‌دهنده بخواهد از یک commit مشخص استفاده کند، اما آن commit هنوز به عنوان یک نسخه رسمی تگ نشده است.

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
🗣️ Do Gophers Really Tend to Build Everything From Scratch?

🟢 خلاصه مقاله:
در یک بحث در ردیت، توسعه‌دهنده‌ای که به تازگی با زبان برنامه‌نویسی Go آشنا شده بود، سوال کرد که چرا در Go تعداد فریمورک‌های بزرگ کم است و آیا معمولاً همه چیز را از ابتدا می‌سازیم. پاسخ برتر به خوبی رویکرد معمول به زبان Go را خلاصه می‌کند: ما تعداد زیادی کتابخانه عالی داریم و Go این امکان را فراهم می‌کند که آن‌ها را به راحتی با هم ترکیب کنیم. این تبادل نظر به بحث بیشتری در مورد چگونگی بهره‌گیری و ترکیب کتابخانه‌ها در Go برای توسعه نرم‌افزار به جای تکیه بر فریمورک‌های بزرگ و جامع منجر شد، که این موضوع نشان‌دهنده تمایل توسعه‌دهندگان Go به استفاده از رویکردهای ساده‌تر و مدولارتر است.

🟣لینک مقاله:
https://www.reddit.com/r/golang/comments/1cmk0bp/from_python_to_go_do_you_really_tend_to_build/l3170pi/

➖➖➖➖➖➖➖➖
👑 @gopher_academy

خط زیر در فایل go.work.sum یه نمونه هست از یک کتابخونه که مربوط به مدیریت ماژول‌ها و وابستگی‌های پروژه Go است:

modernc.org/ccgo/v3 v3.16.6/go.mod h1:tGtX0gE9Jn7hdZFeU88slbTh1UtCYKusWOoCJuvkWsQ=

این خط شامل اطلاعات زیر است:

1. modernc.org/ccgo/v3:
   - این بخش نام ماژول است. در اینجا، ماژول ccgo از مسیر modernc.org/ccgo/v3 وارد شده است.

2. v3.16.6/go.mod:
   - این قسمت نسخه‌ای از ماژول را که به آن ارجاع داده شده است، مشخص می‌کند. در اینجا، نسخه v3.16.6 مورد استفاده قرار گرفته است. همچنین، این مشخص می‌کند که این خط به فایل go.mod این نسخه اشاره دارد.

3. h1:tGtX0gE9Jn7hdZFeU88slbTh1UtCYKusWOoCJuvkWsQ=:
   - این قسمت یک هش رمزنگاری است (هشینگ شده با الگوریتم SHA-256) که برای تأیید صحت و یکپارچگی فایل go.mod برای این ماژول استفاده می‌شود. این هش تضمین می‌کند که فایل go.mod مربوط به این ماژول و نسخه‌ی خاص آن بدون تغییر است و همان نسخه‌ای است که در ابتدا دانلود و استفاده شده است.

### مفهوم کلی:
این خط به Go می‌گوید که ماژول ccgo نسخه v3.16.6 از مسیر modernc.org/ccgo/v3 استفاده شده و صحت فایل go.mod آن با هش مشخص شده تایید می‌شود. این اطلاعات در فایل go.work.sum ذخیره می‌شود تا اطمینان حاصل شود که تمامی وابستگی‌ها در پروژه به درستی مدیریت می‌شوند و هیچگونه تغییر ناخواسته‌ای در فایل‌های ماژول‌ها ایجاد نشده است.
➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Tips for Building Bubble Tea Programs

🟢 خلاصه مقاله:
مقاله‌ای که به بررسی و ارزیابی Bubble Tea، یک فریم‌ورک قوی به زبان Go برای ساخت رابط‌های کاربری ترمینال (TUIs) می‌پردازد، تجارب لوییس را در ساخت PUG، یک TUI برای Terraform، به اشتراک می‌گذارد. لوییس وقت زیادی را برای توسعه PUG صرف کرده است و در این مقاله، نکات کلیدی و درس‌هایی که از این تجربه آموخته شده، بیان می‌شود. این مقاله علاوه بر معرفی کاربردها و ویژگی‌های Bubble Tea، بر روی چگونگی استفاده از این فریم‌ورک به منظور بهینه‌سازی و افزایش کارآمدی رابط‌های کاربری ترمینال تمرکز دارد.

🟣لینک مقاله:
https://golangweekly.com/link/159225/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

📢اگر دنبال نکات طلایی و مطالب بروز مربوط به انواع دیتابیس ها هستی

ما توی چنل زیر بیشتر دیتابیس های زیر رو مورد بررسی قرار میدیم👇

🔵Postgresql
🔵Redis
🔵Mysql
🔵Mongodb

🔴 سعی میشه توی چنل زیر بروز ترین مطالبی دیتابیس های فوق رو بزاریم


👇👇چنل ما👇👇

@database_academy

در گولنگ ما دوتا از تکنیک استفاده می کنیم که به آن type assertion یا interface satisfaction checking گفته می‌شود. بیایید تفاوت‌ها را بررسی کنیم:

### 1. var _ io.ReadWriter = (*T)(nil)

این عبارت برای اطمینان از این استفاده می‌شود که نوع T از اینترفیس io.ReadWriter پیروی می‌کند. این یک تکنیک برای تایید کامپایل‌تایم است.

- هدف: بررسی می‌کند که نوع T تمام متدهای مورد نیاز برای اینترفیس io.ReadWriter را پیاده‌سازی کرده است.
- نحوه‌ی عملکرد: با اختصاص یک مقدار nil به یک اشاره‌گر از نوع T و سپس بررسی اینکه آیا می‌تواند به عنوان یک io.ReadWriter مورد استفاده قرار بگیرد، اگر نوع T همه متدهای مورد نیاز را نداشته باشد، کامپایلر ارور خواهد داد.
- استفاده در توسعه: این تکنیک به طور رایج برای ایمن‌سازی کد و جلوگیری از مشکلات پیاده‌سازی اینترفیس‌ها در زمان کامپایل استفاده می‌شود.

مثال:

type T struct{}

func (t *T) Read(p []byte) (n int, err error) {
    return 0, nil
}

func (t *T) Write(p []byte) (n int, err error) {
    return len(p), nil
}

// تایید می‌کند که T از io.ReadWriter پیروی می‌کند.
var _ io.ReadWriter = (*T)(nil)

در اینجا، اگر T متدهای Read و Write را نداشته باشد، کامپایلر خطا می‌دهد.

### 2. var PaymentInstance PaymentProcessor = nil

این عبارت برای تعریف یک متغیر از نوع PaymentProcessor و مقداردهی اولیه آن به nil است. در اینجا PaymentProcessor یک اینترفیس فرضی است و شما متغیری به نام PaymentInstance را به عنوان نوع اینترفیس تعریف می‌کنید و فعلاً مقدار آن nil است.

- هدف: تعریف یک متغیر از نوع اینترفیس PaymentProcessor که فعلاً به هیچ مقداری یا پیاده‌سازی‌ای اختصاص داده نشده است.
- نحوه‌ی عملکرد: این متغیر می‌تواند در آینده به یک مقداری که نوع آن پیاده‌سازی‌کننده‌ی اینترفیس PaymentProcessor است، مقداردهی شود.
- استفاده در توسعه: این مورد بیشتر برای مقداردهی اولیه و آماده‌سازی یک متغیر برای استفاده‌های بعدی است.

مثال:

type PaymentProcessor interface {
    ProcessPayment(amount float64) error
}

var PaymentInstance PaymentProcessor = nil

// بعداً می‌توانیم به PaymentInstance یک پیاده‌سازی خاص بدهیم:
type PayPalProcessor struct{}

func (p *PayPalProcessor) ProcessPayment(amount float64) error {
    // پردازش پرداخت
    return nil
}

PaymentInstance = &PayPalProcessor{}

### تفاوت‌ها

- عبارت اول (`var _ io.ReadWriter = (*T)(nil)`): یک چک کردن کامپایل‌تایم است تا مطمئن شویم نوع T اینترفیس io.ReadWriter را پیاده‌سازی کرده است.

- عبارت دوم (`var PaymentInstance PaymentProcessor = nil`): یک متغیر از نوع اینترفیس PaymentProcessor تعریف می‌کند و مقدار اولیه آن را nil قرار می‌دهد که برای استفاده‌های بعدی آماده است.

عبارت اول بیشتر برای بررسی صحیح بودن پیاده‌سازی اینترفیس‌ها در زمان کامپایل استفاده می‌شود، در حالی که عبارت دوم برای مقداردهی اولیه متغیرها در زمان اجرا و مدیریت پیاده‌سازی‌های مختلف اینترفیس‌ها استفاده می‌شود.
➖➖➖➖➖➖➖➖
👑 @gopher_academy

هنگامی که دارید کد هاتون رو کامیت می کنید هیچ وقت کد های کامنت شده رو کامیت نکنید این باعث کثیف شدن پایگاه کد هاتون می شود و همچنین این باعث میشه از اصل کنترل ورژن دورتر شوید.

کثیف شدن پایگاه کد
وقتی که کدهای کامنتشده را در مخزن (Repository) خود کامیت میکنید، این کدها به عنوان بخشی از تاریخچهی پروژه شما ذخیره میشوند. این موضوع باعث میشود که پایگاه کد شما پر از کدهای مرده، غیرقابل استفاده و غیرقابل پیگیری شود. به مرور زمان، این کدها میتوانند باعث افزایش پیچیدگی پروژه شوند و درک کدها را برای توسعهدهندگان جدید و حتی خودتان در آینده دشوار کنند.

دوری از اصل کنترل ورژن:
یکی از اصول مهم کنترل ورژن این است که هر تغییر در کد به دقت مستند شود و تاریخچهی تغییرات به صورت واضح و قابل پیگیری باشد. زمانی که شما کدهای کامنتشده را کامیت میکنید، در واقع دارید کدی را ذخیره میکنید که نه کامل است و نه مشخص است که چرا کامنت شده. این باعث میشود که دلایل تغییرات به درستی مستند نشود و در آینده برای شما یا همکارانتان فهمیدن دلیل این کامنتها و بازگرداندن کدهای صحیح دشوار شود.

پایبندی به فلسفه کد تمیز:
کد تمیز (Clean Code) به معنای کدی است که خوانا، قابل فهم و بدون شلوغیهای اضافی باشد. وجود کدهای کامنتشده در مخزن شما برخلاف این فلسفه است، زیرا این کدها میتوانند باعث ایجاد ابهام و سردرگمی شوند. مثلاً ممکن است یک توسعهدهنده دیگر از خودش بپرسد که آیا این کد کامنتشده باید به کد اصلی اضافه شود یا نه. این موضوع میتواند باعث کاهش بهرهوری و ایجاد خطاهای غیرمنتظره در آینده شود.


راه حلهای جایگزین:
اگر نیاز دارید که کدی را برای مدت کوتاهی از اجرا خارج کنید ولی همچنان میخواهید آن را به یاد داشته باشید، میتوانید از امکانات کنترل ورژن استفاده کنید. به عنوان مثال، میتوانید آن کد را به یک شاخه (branch) جداگانه منتقل کنید. در این صورت، هم تاریخچهی پروژه تمیز باقی میماند و هم شما به راحتی میتوانید در صورت نیاز به آن کد دسترسی داشته باشید.

خلاصه کلام :
در مجموع، کامیت کردن کدهای کامنتشده نه تنها باعث کثیف شدن پایگاه کد میشود بلکه میتواند اصول کنترل ورژن را زیر سوال ببرد و درک و نگهداری پروژه را برای شما و همکارانتان در آینده دشوارتر کند. به جای کامیت کردن کدهای کامنتشده، سعی کنید از ابزارهای کنترل ورژن و مدیریت پروژه به درستی استفاده کنید تا پایگاه کد تمیزی داشته باشید.

DevTwitter | <Mohammad Abdorrahmani/>
➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Stytch: Auth0 Alternative for AuthN, AuthZ, Fraud Prevention

🟢 خلاصه مقاله:
مقاله به بررسی امکانات و خدمات Stytch در زمینه احراز هویت B2B چند-مستاجری در سطح شرکت‌ها می‌پردازد. Stytch امکان استفاده از SSO (ورود یکباره)، RBAC (کنترل دسترسی براساس نقش) و SCIM (مدیریت هویت و دسترسی مبتنی بر استانداردهای ابری) را فراهم می‌کند. همچنین، این سرویس قابلیت استفاده از رابط‌های کاربری از پیش ساخته شده، بدون رابط کاربری (headless)، و یا ادغام مستقیم با API را ارائه می‌دهد. یکی از ویژگی‌های مهم Stytch شناسایی دیجیتالی دستگاه‌هاست تا از طریق آن بتوان ردیابی بات‌ها را انجام داد و از سوءاستفاده جلوگیری کرد. استفاده از Stytch با نسخه رایگان نیز آغاز می‌شود، که این امکان به کاربران اجازه می‌دهد تا کارایی و اثربخشی این سرویس را قبل از خرید تجربه کنند.

🟣لینک مقاله:
https://stytch.com?utm_source=go-weekly&utm_medium=paid_sponsorship&utm_content=go-weekly-05-14-2024&utm_campaign=go-weekly-05-14-2024

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Reclaiming CPU for Free with PGO

🟢 خلاصه مقاله:
مقاله‌ای که به بررسی تجربیات شرکت‌های Dolt و Cloudflare با استفاده از بهینه‌سازی مبتنی بر نمایه (PGO) در نسخه 1.20 و بالاتر زبان برنامه‌نویسی Go پرداخته، نشان می‌دهد که Cloudflare به طور خاص سود بزرگی از این فناوری برده است. با توجه به مقیاس بزرگ استفاده از خدمات مبتنی بر Go در Cloudflare، که شامل هزاران هسته می‌شود، نتایج حاصله از این بهینه‌سازی بسیار چشمگیر است. این بهینه‌سازی که در نسخه‌های جدیدتر Go اعمال شده، به طور موثری عملکرد برنامه‌ها را بهبود می‌بخشد، و Cloudflare توانسته از این روش برای افزایش کارایی و بهره‌وری در مقیاس وسیع بهره‌مند شود. در نتیجه، مقاله بر اهمیت انتخاب این فناوری‌های نوین در توسعه و استقرار سیستم‌های نرم‌افزاری در سطوح بالای عملیاتی تاکید می‌کند.

🟣لینک مقاله:
https://blog.cloudflare.com/reclaiming-cpu-for-free-with-pgo/

➖➖➖➖➖➖➖➖
👑 @gopher_academy