💠 نسخه جدید محیط توسعه Zed منتشر شده است
🔸 ارتقا از نسخه 1.7.2 به 1.8.2
🔖 #zed, #chat, #release
💎 @DevelopixChannel
🔸 ارتقا از نسخه 1.7.2 به 1.8.2
🔖 #zed, #chat, #release
💎 @DevelopixChannel
👍6
💠 نسخه جدید محیط توسعه VSCode منتشر شده است
🔸 ارتقا از نسخه 1.126.0 به 1.127.0
🔖 #vscode, #chat, #release
💎 @DevelopixChannel
🔸 ارتقا از نسخه 1.126.0 به 1.127.0
🔖 #vscode, #chat, #release
💎 @DevelopixChannel
👍1
راز کندی کدهای مالتیترد: کابوسی به نام False Sharing
تا حالا برات پیش اومده یه کد مالتیترد بنویسی، هیچ Lockای هم استفاده نکنی، تردها کاملاً مستقل از هم کار کنن، ولی آخرش ببینی از نسخهی تکترد هم کندتره؟
اگر جواب مثبته، احتمالاً با یکی از عجیبترین و پنهانترین مشکلات دنیای سختافزار روبهرو شدی: False Sharing.
پشت صحنهی CPU چه خبره؟
پردازندههای امروزی دادهها رو دونهدونه از RAM نمیخونن. اونها دادهها رو در بستههایی به اسم Cache Line (معمولاً ۶۴ بایت) داخل حافظهی کش (L1/L2/L3) نگه میدارن تا دسترسی بهشون خیلی سریعتر باشه.
حالا فرض کن این ساختار رو داریم:
type CoreData struct {
CounterA int64 // ۸ بایت
CounterB int64 // ۸ بایت
}
چون این دو متغیر کنار هم قرار گرفتن، احتمالاً هر دو داخل یک Cache Line قرار میگیرن.
مشکل از کجا شروع میشه؟
فرض کن:
ترد اول روی هستهی اول CPU مدام CounterA رو تغییر میده.
ترد دوم روی هستهی دوم CPU هم مدام CounterB رو آپدیت میکنه.
از دید برنامهنویس، این دو متغیر هیچ ارتباطی با هم ندارن. اما از دید CPU داستان فرق میکنه.
هر بار که هستهی اول CounterA رو تغییر میده، کل اون Cache Line برای هستهی دوم نامعتبر (Invalid) میشه. هستهی دوم مجبور میشه دوباره داده رو از کش سطح بالاتر یا حتی RAM بخونه، مقدار خودش رو تغییر بده و دوباره باعث نامعتبر شدن کش هستهی اول بشه.
این رفتوبرگشت دائمی بین هستهها رو Cache Line Bouncing میگن.
نتیجه چیه؟ پردازنده به جای اینکه وقتش رو صرف اجرای کد تو کنه، مدام مشغول هماهنگ کردن حافظهی کش بین هستههاست!
راهحل؟ Padding
خوشبختانه راهحلش خیلی پیچیده نیست.
کافیه کاری کنیم این دو متغیر داخل یک Cache Line قرار نگیرن. یعنی بینشون کمی فاصله (Padding) ایجاد کنیم تا هر کدوم روی یک Cache Line جدا باشن.
مثلاً در Go میتونیم از cpu.CacheLinePad استفاده کنیم:
import "golang.org/x/sys/cpu"
type OptimizedData struct {
CounterA int64
_ cpu.CacheLinePad
CounterB int64
}
با همین فاصلهی ساده، هر متغیر روی یک Cache Line جدا قرار میگیره و دو هسته بدون اینکه مزاحم هم بشن، همزمان کار میکنن.
جالبتر اینکه در بعضی بنچمارکهای واقعی، همین تغییر کوچک تونسته عملکرد کدهای موازی رو چند برابر و حتی تا ۱۰ برابر بهتر کنه.
حرف آخر
خیلی وقتها مشکل کند بودن کد، نه از الگوریتمه، نه از زبان برنامهنویسی و نه حتی از تعداد Threadها؛ بلکه از جزئیاتی میاد که داخل خود CPU اتفاق میافته.
هرچقدر درک بهتری از معماری سختافزار داشته باشیم، راحتتر میتونیم کدهایی بنویسیم که علاوه بر درست بودن، واقعاً سریع هم باشن.
🔖 #Programming #برنامه_نویسی
👤 Ruhollah
💎 Channel: @DevelopixChannel
تا حالا برات پیش اومده یه کد مالتیترد بنویسی، هیچ Lockای هم استفاده نکنی، تردها کاملاً مستقل از هم کار کنن، ولی آخرش ببینی از نسخهی تکترد هم کندتره؟
اگر جواب مثبته، احتمالاً با یکی از عجیبترین و پنهانترین مشکلات دنیای سختافزار روبهرو شدی: False Sharing.
پشت صحنهی CPU چه خبره؟
پردازندههای امروزی دادهها رو دونهدونه از RAM نمیخونن. اونها دادهها رو در بستههایی به اسم Cache Line (معمولاً ۶۴ بایت) داخل حافظهی کش (L1/L2/L3) نگه میدارن تا دسترسی بهشون خیلی سریعتر باشه.
حالا فرض کن این ساختار رو داریم:
type CoreData struct {
CounterA int64 // ۸ بایت
CounterB int64 // ۸ بایت
}
چون این دو متغیر کنار هم قرار گرفتن، احتمالاً هر دو داخل یک Cache Line قرار میگیرن.
مشکل از کجا شروع میشه؟
فرض کن:
ترد اول روی هستهی اول CPU مدام CounterA رو تغییر میده.
ترد دوم روی هستهی دوم CPU هم مدام CounterB رو آپدیت میکنه.
از دید برنامهنویس، این دو متغیر هیچ ارتباطی با هم ندارن. اما از دید CPU داستان فرق میکنه.
هر بار که هستهی اول CounterA رو تغییر میده، کل اون Cache Line برای هستهی دوم نامعتبر (Invalid) میشه. هستهی دوم مجبور میشه دوباره داده رو از کش سطح بالاتر یا حتی RAM بخونه، مقدار خودش رو تغییر بده و دوباره باعث نامعتبر شدن کش هستهی اول بشه.
این رفتوبرگشت دائمی بین هستهها رو Cache Line Bouncing میگن.
نتیجه چیه؟ پردازنده به جای اینکه وقتش رو صرف اجرای کد تو کنه، مدام مشغول هماهنگ کردن حافظهی کش بین هستههاست!
راهحل؟ Padding
خوشبختانه راهحلش خیلی پیچیده نیست.
کافیه کاری کنیم این دو متغیر داخل یک Cache Line قرار نگیرن. یعنی بینشون کمی فاصله (Padding) ایجاد کنیم تا هر کدوم روی یک Cache Line جدا باشن.
مثلاً در Go میتونیم از cpu.CacheLinePad استفاده کنیم:
import "golang.org/x/sys/cpu"
type OptimizedData struct {
CounterA int64
_ cpu.CacheLinePad
CounterB int64
}
با همین فاصلهی ساده، هر متغیر روی یک Cache Line جدا قرار میگیره و دو هسته بدون اینکه مزاحم هم بشن، همزمان کار میکنن.
جالبتر اینکه در بعضی بنچمارکهای واقعی، همین تغییر کوچک تونسته عملکرد کدهای موازی رو چند برابر و حتی تا ۱۰ برابر بهتر کنه.
حرف آخر
خیلی وقتها مشکل کند بودن کد، نه از الگوریتمه، نه از زبان برنامهنویسی و نه حتی از تعداد Threadها؛ بلکه از جزئیاتی میاد که داخل خود CPU اتفاق میافته.
هرچقدر درک بهتری از معماری سختافزار داشته باشیم، راحتتر میتونیم کدهایی بنویسیم که علاوه بر درست بودن، واقعاً سریع هم باشن.
🔖 #Programming #برنامه_نویسی
👤 Ruhollah
💎 Channel: @DevelopixChannel
👍4❤1
💠 نسخه جدید محیط توسعه Zed منتشر شده است
🔸 ارتقا از نسخه 1.8.2 به 1.9.0
🔖 #zed, #chat, #release
💎 @DevelopixChannel
🔸 ارتقا از نسخه 1.8.2 به 1.9.0
🔖 #zed, #chat, #release
💎 @DevelopixChannel
👍3
قانون Demeter (Law of Demeter) چیه و چرا اینقدر مهمه؟ 🤐
یکی از اصول قدیمی ولی فوقالعاده کاربردی در طراحی شیگرا، Law of Demeter یا همون "Talk only to your friends" ـه.
به زبان ساده: هر آبجکت فقط باید با "همسایههای نزدیکش" حرف بزنه، نه با نصف سیستم.
قاعدهٔ اصلی:
هر متد فقط باید با اینها تعامل داشته باشه:
• خودِ شی (this)
• پارامترهای ورودی متد
• فیلدهای خودش
• آبجکتهایی که خودش میسازه
هر چیزی غیر از این، بوی Coupling بالا و دردسر در ریفکتور میده 😄
یک مثال بد 👎 (Law of Demeter نقض شده)
توی کد واقعی (مثال Python):
اینجا
• اگر ساختار
• اگر
نسخهٔ بهتر ✅ (رعایت Law of Demeter)
مسیر طولانی رو "کپسوله" میکنیم:
حالا
چرا این قانون در عمل خیلی کمک میکنه؟ 💡
• کاهش Coupling: کلاسها کمتر از ساختار داخلی هم خبر دارن.
• انعطاف در ریفکتور: راحت میتونی مدل داده رو عوض کنی بدون اینکه نصف سرویسها رو دست بزنی.
• بهبود تستپذیری: با Mock کردن چند آبجکت محدود میتونی یونیتتست بنویسی، بدون زنجیرههای عجیب.
بوی بد معروف: "Train Wreck" 🚂
هر وقت این الگو رو دیدی:
تقریباً مطمئنی که Law of Demeter نقض شده. این همون Train Wreck ـه؛ قطار نقطهها.
چند نکتهٔ عملی برای کدنویسی روزمره
• اگر
• به جای expose کردن کل آبجکتهای داخلی، متدهای سطح بالاتر ارائه کن (مثل
• توی Serviceها از Facade-های کوچک استفاده کن تا از جزئیات Domain دور نگهشون داری.
منابع بیشتر 📚
• Martin Fowler — Law of Demeter
• Refactoring Guru — Message Chains
از همین امروز، هر جا "قطار نقطهها" دیدی، یک مکث کوتاه و یک ریفکتور کوچک میتونه معماری کدت رو حسابی تمیزتر کنه 🌱
🔖 #Programming #برنامه_نویسی #Law_of_Demeter #Clean_Code #Coupling #Design_Principles #OOP #Refactoring #Architecture
👤 Developix
💎 Channel: @DevelopixChannel
یکی از اصول قدیمی ولی فوقالعاده کاربردی در طراحی شیگرا، Law of Demeter یا همون "Talk only to your friends" ـه.
به زبان ساده: هر آبجکت فقط باید با "همسایههای نزدیکش" حرف بزنه، نه با نصف سیستم.
قاعدهٔ اصلی:
هر متد فقط باید با اینها تعامل داشته باشه:
• خودِ شی (this)
• پارامترهای ورودی متد
• فیلدهای خودش
• آبجکتهایی که خودش میسازه
هر چیزی غیر از این، بوی Coupling بالا و دردسر در ریفکتور میده 😄
یک مثال بد 👎 (Law of Demeter نقض شده)
order.customer.address.city
توی کد واقعی (مثال Python):
class OrderService:
def get_customer_city(self, order):
return order.customer.address.city
اینجا
OrderService داره نصف مدل دامنه رو میگرده:• اگر ساختار
Customer عوض بشه، اینجا هم میترکه.• اگر
Address حذف بشه یا تغییر کنه، باز این کلاس میشکنه.نسخهٔ بهتر ✅ (رعایت Law of Demeter)
مسیر طولانی رو "کپسوله" میکنیم:
class Customer:
def get_city(self):
return self.address.city
class Order:
def get_customer_city(self):
return self.customer.get_city()
class OrderService:
def get_customer_city(self, order):
return order.get_customer_city()
حالا
OrderService فقط با Order حرف میزنه. بقیهاش پشت متدها مخفیه. اگر فردا مدل آدرس عوض بشه، فقط داخل Customer و حداکثر Order رو آپدیت میکنی.چرا این قانون در عمل خیلی کمک میکنه؟ 💡
• کاهش Coupling: کلاسها کمتر از ساختار داخلی هم خبر دارن.
• انعطاف در ریفکتور: راحت میتونی مدل داده رو عوض کنی بدون اینکه نصف سرویسها رو دست بزنی.
• بهبود تستپذیری: با Mock کردن چند آبجکت محدود میتونی یونیتتست بنویسی، بدون زنجیرههای عجیب.
بوی بد معروف: "Train Wreck" 🚂
هر وقت این الگو رو دیدی:
a.b().c.d().e
تقریباً مطمئنی که Law of Demeter نقض شده. این همون Train Wreck ـه؛ قطار نقطهها.
چند نکتهٔ عملی برای کدنویسی روزمره
• اگر
. زیاد پشت سر هم میبینی، معمولاً یعنی لازمه چندتا متد کوچک "واسط" اضافه کنی.• به جای expose کردن کل آبجکتهای داخلی، متدهای سطح بالاتر ارائه کن (مثل
getCustomerCity()).• توی Serviceها از Facade-های کوچک استفاده کن تا از جزئیات Domain دور نگهشون داری.
منابع بیشتر 📚
• Martin Fowler — Law of Demeter
• Refactoring Guru — Message Chains
از همین امروز، هر جا "قطار نقطهها" دیدی، یک مکث کوتاه و یک ریفکتور کوچک میتونه معماری کدت رو حسابی تمیزتر کنه 🌱
🔖 #Programming #برنامه_نویسی #Law_of_Demeter #Clean_Code #Coupling #Design_Principles #OOP #Refactoring #Architecture
👤 Developix
💎 Channel: @DevelopixChannel
👍6
💠 نسخه جدید محیط توسعه VSCode منتشر شده است
🔸 ارتقا از نسخه 1.127.0 به 1.128.0
🔖 #vscode, #chat, #release
💎 @DevelopixChannel
🔸 ارتقا از نسخه 1.127.0 به 1.128.0
🔖 #vscode, #chat, #release
💎 @DevelopixChannel
👍1
💠 نسخه جدید محیط توسعه Zed منتشر شده است
🔸 ارتقا از نسخه 1.9.0 به 1.10.0
🔖 #zed, #chat, #release
💎 @DevelopixChannel
🔸 ارتقا از نسخه 1.9.0 به 1.10.0
🔖 #zed, #chat, #release
💎 @DevelopixChannel
👍2
💠 نسخه جدید محیط توسعه VSCode منتشر شده است
🔸 ارتقا از نسخه 1.128.1 به 1.129.0
🔖 #vscode, #chat, #release
💎 @DevelopixChannel
🔸 ارتقا از نسخه 1.128.1 به 1.129.0
🔖 #vscode, #chat, #release
💎 @DevelopixChannel
💠 نسخه جدید محیط توسعه ویژوال استودیو (Visual Studio) منتشر شده است
🔸 ارتقا از نسخه 18.7.4 به 18.8.0
🔖 #visual_studio, #chat, #csharp, #release
💎 @DevelopixChannel
🔸 ارتقا از نسخه 18.7.4 به 18.8.0
🔖 #visual_studio, #chat, #csharp, #release
💎 @DevelopixChannel
💠 نسخه جدید محیط توسعه Zed منتشر شده است
🔸 ارتقا از نسخه 1.10.3 به 1.11.3
🔖 #zed, #chat, #release
💎 @DevelopixChannel
🔸 ارتقا از نسخه 1.10.3 به 1.11.3
🔖 #zed, #chat, #release
💎 @DevelopixChannel
نامگذاری تمیز؛ اولین خط دفاع در Clean Code 🧹
یکی از عملیترین ایدههای کتاب Clean Code این است که «اسم خوب، نصف راه خوانایی کد است». خیلی از بدهیهای فنی فقط با نامگذاری درست اصلاً بهوجود نمیآیند.
👀 نشانههای نامگذاری بد
وقتی متغیر و تابع اینطوری هستند:
از روی اسمها تقریباً هیچ چیز قابلفهم نیست. برای فهمیدن کد، مجبور میشویم پیادهسازی داخلی را خطبهخط بخوانیم.
✅ چطور بهترش کنیم؟
۱️⃣ اسم باید «بگوید» چهکار میکند
نام تابع، ورودی و شرطها واضح شدهاند. نیاز کمتری به کامنت داریم، چون خود کد توضیحدهنده است.
۲️⃣ از اسمهای عمومی مثل data, info, tmp دوری کن
هرجا اسم مبهم میشود، خواننده باید در ذهنش حدس بزند؛ همین حدسها منبع اصلی سوتفاهم در کد هستند.
۳️⃣ اسم تابع را فعل، اسم متغیر را اسم بگذار
این الگوی ساده کمک میکند بدون نگاه به بدنه، از روی اسمها بفهمیم هر چیزی «چیز است» یا «کار».
۴️⃣ از abbreviation بیمعنی خودداری کن
خودمان امروز معنای cfg را میفهمیم، ۶ ماه بعد یا برای همکار جدید، این تبدیل میشود به رمز.
۵️⃣ اسمها را بر اساس domain انتخاب کن
استفاده از واژههای همان دامنه (Order, Invoice, Payment, Discount) کد را به زبان بیزینس نزدیک میکند و فهم سیستم را برای همهی تیم آسانتر میکند.
📚 برای مطالعه بیشتر:
Clean Code, Chapter 2: Meaningful Names
Refactoring Guru - Code Smells
در هر refactor کوچک، فقط با بهتر کردن اسمها میشود کیفیت طراحی را بالا برد؛ بدون تغییر رفتار کد. از همین commit بعدی، روی هر اسم چند ثانیه بیشتر فکر شود، بازدهش در بلندمدت شگفتانگیز است ✨
🔖 #Programming #برنامه_نویسی #clean_code #naming #meaningful_names #refactoring #readability #architecture
👤 Developix
💎 Channel: @DevelopixChannel
یکی از عملیترین ایدههای کتاب Clean Code این است که «اسم خوب، نصف راه خوانایی کد است». خیلی از بدهیهای فنی فقط با نامگذاری درست اصلاً بهوجود نمیآیند.
👀 نشانههای نامگذاری بد
وقتی متغیر و تابع اینطوری هستند:
def p(u):
if len(u) > 0:
for x in u:
if x[3] == 1:
send(x)
از روی اسمها تقریباً هیچ چیز قابلفهم نیست. برای فهمیدن کد، مجبور میشویم پیادهسازی داخلی را خطبهخط بخوانیم.
✅ چطور بهترش کنیم؟
۱️⃣ اسم باید «بگوید» چهکار میکند
def send_active_users(users):
if len(users) == 0:
return
for user in users:
if user.is_active():
send(user)
نام تابع، ورودی و شرطها واضح شدهاند. نیاز کمتری به کامنت داریم، چون خود کد توضیحدهنده است.
۲️⃣ از اسمهای عمومی مثل data, info, tmp دوری کن
# بد
result = process(data)
# بهتر
normalized_orders = normalize_orders(raw_orders)
هرجا اسم مبهم میشود، خواننده باید در ذهنش حدس بزند؛ همین حدسها منبع اصلی سوتفاهم در کد هستند.
۳️⃣ اسم تابع را فعل، اسم متغیر را اسم بگذار
# تابع با اسم اسمی (بدفهم)
user_status = user()
# واضحتر
status = get_user_status()
این الگوی ساده کمک میکند بدون نگاه به بدنه، از روی اسمها بفهمیم هر چیزی «چیز است» یا «کار».
۴️⃣ از abbreviation بیمعنی خودداری کن
# بد
cfg = read_cfg(pth)
# بهتر
config = read_config_file(path)
خودمان امروز معنای cfg را میفهمیم، ۶ ماه بعد یا برای همکار جدید، این تبدیل میشود به رمز.
۵️⃣ اسمها را بر اساس domain انتخاب کن
استفاده از واژههای همان دامنه (Order, Invoice, Payment, Discount) کد را به زبان بیزینس نزدیک میکند و فهم سیستم را برای همهی تیم آسانتر میکند.
📚 برای مطالعه بیشتر:
Clean Code, Chapter 2: Meaningful Names
Refactoring Guru - Code Smells
در هر refactor کوچک، فقط با بهتر کردن اسمها میشود کیفیت طراحی را بالا برد؛ بدون تغییر رفتار کد. از همین commit بعدی، روی هر اسم چند ثانیه بیشتر فکر شود، بازدهش در بلندمدت شگفتانگیز است ✨
🔖 #Programming #برنامه_نویسی #clean_code #naming #meaningful_names #refactoring #readability #architecture
👤 Developix
💎 Channel: @DevelopixChannel
❤4
Forwarded from Developix Support
با Migration Boost هاستایران، برای مهاجرت به سرور ابری دوباره هزینه ترافیک نده! 🚀
با خرید اولین سرور ابری غیرساعتی از **هاستایران**، بسته ترافیک هدیه مهاجرت بهصورت خودکار برای سرویس شما فعال میشود:
✅ حداقل ۱۰۰ گیگابایت ترافیک هدیه مهاجرت
✅ افزایش حجم هدیه متناسب با ظرفیت دیسک اولیه
✅ ترافیک آپلود رایگان
✅ بدون محدودیت زمانی
سرور ابری هاستایران را راهاندازی کنید و بکاپها، فایلها و پایگاه داده خود را بدون دغدغه هزینههای پنهان ترافیک منتقل کنید.
👇 مشاهده پلنهای سرور ابری هاستایران
hostiran.club/Migration
hostiran.club/Migration
با خرید اولین سرور ابری غیرساعتی از **هاستایران**، بسته ترافیک هدیه مهاجرت بهصورت خودکار برای سرویس شما فعال میشود:
✅ حداقل ۱۰۰ گیگابایت ترافیک هدیه مهاجرت
✅ افزایش حجم هدیه متناسب با ظرفیت دیسک اولیه
✅ ترافیک آپلود رایگان
✅ بدون محدودیت زمانی
سرور ابری هاستایران را راهاندازی کنید و بکاپها، فایلها و پایگاه داده خود را بدون دغدغه هزینههای پنهان ترافیک منتقل کنید.
👇 مشاهده پلنهای سرور ابری هاستایران
hostiran.club/Migration
hostiran.club/Migration
💠 نسخه جدید محیط توسعه VSCode منتشر شده است
🔸 ارتقا از نسخه 1.130.0 به 1.131.0
🔖 #vscode, #chat, #release
💎 @DevelopixChannel
🔸 ارتقا از نسخه 1.130.0 به 1.131.0
🔖 #vscode, #chat, #release
💎 @DevelopixChannel
👍1
💠 نسخه جدید محیط توسعه Zed منتشر شده است
🔸 ارتقا از نسخه 1.12.1 به 1.13.1
🔖 #zed, #chat, #release
💎 @DevelopixChannel
🔸 ارتقا از نسخه 1.12.1 به 1.13.1
🔖 #zed, #chat, #release
💎 @DevelopixChannel
👍1
در نمونهکد بالا، استفاده از آرگومان پیشفرض قابلتغییر (مثل
🔖 #Programming #برنامه_نویسی
👤 Developix
💎 Channel: @DevelopixChannel
list) در تعریف تابع باعث بروز رفتار غیرقابلپیشبینی و Memory Leak منطقی در سناریوهای پیچیده میشود، چون همهٔ فراخوانیها همان آبجکت پیشفرض را بهاشتراک میگذارند. بهجای آن میتوانید با مقدار پیشفرض None و ساخت لیست جدید داخل تابع، هر بار یک state مستقل بسازید و از باگهای سخترفع در کدهای چندماژوله و تستنویسی جلوگیری کنید.🔖 #Programming #برنامه_نویسی
👤 Developix
💎 Channel: @DevelopixChannel
💠 نسخه جدید محیط توسعه VSCode منتشر شده است
🔸 ارتقا از نسخه 1.131.0 به 1.132.0
🔖 #vscode, #chat, #release
💎 @DevelopixChannel
🔸 ارتقا از نسخه 1.131.0 به 1.132.0
🔖 #vscode, #chat, #release
💎 @DevelopixChannel
👍1
💠 نسخه جدید محیط توسعه Zed منتشر شده است
🔸 ارتقا از نسخه 1.13.2 به 1.14.2
🔖 #zed, #chat, #release
💎 @DevelopixChannel
🔸 ارتقا از نسخه 1.13.2 به 1.14.2
🔖 #zed, #chat, #release
💎 @DevelopixChannel
👍1
💠 نسخه جدید محیط توسعه VSCode منتشر شده است
🔸 ارتقا از نسخه 1.132.1 به 1.133.0
🔖 #vscode, #chat, #release
💎 @DevelopixChannel
🔸 ارتقا از نسخه 1.132.1 به 1.133.0
🔖 #vscode, #chat, #release
💎 @DevelopixChannel
👍1
💠 نسخه جدید محیط توسعه Zed منتشر شده است
🔸 ارتقا از نسخه 1.14.2 به 1.15.0
🔖 #zed, #chat, #release
💎 @DevelopixChannel
🔸 ارتقا از نسخه 1.14.2 به 1.15.0
🔖 #zed, #chat, #release
💎 @DevelopixChannel
❤2
💠 نسخه جدید محیط توسعه ویژوال استودیو (Visual Studio) منتشر شده است
🔸 ارتقا از نسخه 18.8.3 به 18.9.0
🔖 #visual_studio, #chat, #csharp, #release
💎 @DevelopixChannel
🔸 ارتقا از نسخه 18.8.3 به 18.9.0
🔖 #visual_studio, #chat, #csharp, #release
💎 @DevelopixChannel
👍3❤1