به زودی فعالیت شروع میشه
یکم صبر کنید خودمونو جمع و جور کنیم😂❤️

بهترین ویدئوی ساخته شده با هوش مصنوعی
بر اساس فیلم عشق، مرگ و ربات‌ها 🔥

یک چینی ظزف چند هفته این ویدیو را ساخته است ✅

— Midjourneyفریم‌های اصلی ؛
— Nano Banana Pro
— Flux 2 Max
— SeeDance 2 تبدیل به ویدیو



🚀 @devsourcech

سلام سلام
ظاهرا باید همه ی پست های بله رو اینجا کپی کنیم و بریم سمت اتوماسیون برای بروز کردن هم زمان بله و تلگرام😅
ابزار خوب؟
N8N
#سامان

بچه ها یه کانال دیگه هم داریم که بد نیست بهش نگاهی بندازید
اونجا فقط ابزار معرفی میکنیم
@tech_screenshot

🚨در ادامه ی پست خیلی خوب مهندس رادمان عزیز٬ بریم یکم از خود گیت بگیم و نقش راهبردیش در تیم ها...

در این ویس در مورد گیت٬ برنچینگ٬ نام گذاری برنچ ها٬ کانفلیکت ها٬ ریبیس٬ مرج و چالش های تیمی و استاندارهایی که باید رعایت کنیم توضیح میدیم.

اگر سوال یا تجربه‌ای درباره این موضوع دارید، به آی‌دی خصوصی من یا گروه پیام بدید؛ حتماً جواب می‌دیم.

اگر این مطلب براتون مفید بود، با زدن روی تیک زیر پست اعلام حضور کنید ✅

#سامان #تکنولوژی #گیت #ویس


⚠️ آدرس کانال در تلگرام( حتما جوین بشید )
🚀 @devsourcech
سایت مستندات برنامه نویسی:
🥇 https://devsource.ir

یه اشتباهی که خیلی از برنامه‌نویس‌ها اول کار انجام میدن اینه که اطلاعات مهم پروژه رو مستقیم داخل کد می‌نویسن.

مثلاً:

- DB Address
- API Key
- Token
- Dev / Production Setting

اوایل شاید مشکلی به نظر نرسه، ولی وقتی پروژه بزرگ‌تر میشه یا چند نفر روی اون کار می‌کنن، مدیریت این اطلاعات تبدیل به دردسر میشه.

برای همین از Environment Variable ها استفاده می‌کنیم.

به جای اینکه مقدارها داخل کد باشن، از بیرون به برنامه پاس داده میشن. معمولاً هم داخل فایل ".env" نگهداری میشن.

این کار چند تا مزیت مهم داره:

✅ اطلاعات حساس وارد مخزن Git نمیشن
✅ برای هر محیط (Development، Test، Production) تنظیمات جدا داریم
✅ تغییر تنظیمات بدون دست زدن به کد انجام میشه
✅ امنیت و نگهداری پروژه بهتر میشه

یکی از نشونه‌های پروژه‌های حرفه‌ای اینه که تقریباً هیچ مقدار حساسی رو داخل سورس کد پیدا نمی‌کنید.
کد باید روی منطق کسب‌وکار تمرکز کنه، نه روی اطلاعاتی که ممکنه فردا تغییر کنن.

#رادمان #برنامه‌نویسی #env

‌
⚠️ آدرس کانال در تلگرام( حتما جوین بشید )
🚀 https://t.me/devsourcech
گروه و کانال مربوط مجموعه:
🔸 Gp: @nodemaster
🔹 Ch: @devsource
سایت مستندات برنامه نویسی:
🥇 https://devsource.ir

Rate Limiting یعنی محدود کردن تعداد درخواست‌هایی که یک کاربر یا سرویس می‌تواند در یک بازه زمانی ارسال کند.

Rate Limiting فقط یه عدد نیست
خیلی وقت‌ها وقتی از Rate Limiting حرف می‌زنیم، یه تعریف ساده به ذهن می‌رسه:
هر کاربر مجاز به n درخواست در ثانیه است
اما این تعریف ناقصه. بذارید با یه مثال واقعی شروع کنیم.

مشکل از کجا شروع می‌شه؟
فرض کن یه کاربر فقط ۱۰ درخواست در ثانیه می‌فرسته. کاملاً در محدوده مجاز.
اما هر درخواست ۳۰ ثانیه طول می‌کشه.
10 × 30 = 300 درخواست همزمان
در این حالت، با اینکه Rate Limit نقض نشده، ممکن است Workerها پر شوند، دیتابیس تحت فشار برود و Latency (تاخیر در پاسخ) به شدت افزایش پیدا کند.
به همین دلیل در سیستم‌های بزرگ فقط Rate Limit وجود ندارد :
Rate Limit : تعداد درخواست‌ها رو کنترل می‌کنه
Concurrency Limit : تعداد درخواست‌های همزمان رو محدود می‌کنه
Load Shedding : زیر فشار بالا، ترافیک کم‌اهمیت رو حذف می‌کنه
Resource Limit : درخواست api های سنگین رو جداگانه محدود می‌کنه
بهتره برای اینکه سرور با مشکل رو به رو نشه همه رو با هم چک کنیم

#علی #برنامه_نویسی #ratelimit


🚀 @devsourcech

✅ Claude is cooking ...

دوستانی که windsurf دارن روی اون فعال شده و میتونید تستش کنید.

#AB #AI


🚀 @devsourcech
✅ در بله
🔹 @devsource

🚨 خیلی دوست دارم ابزاری رو معرفی کنم که باهاش می‌تونید از دل کد (چه توی محیط توسعه و چه پروداکشن) کندی‌های سیستم رو با جزئیات کامل بکشید بیرون.

داستان از اینجا شروع میشه که حتماً برای همه‌تون پیش اومده؛ یه ریکوئست میاد، سیستم کنده، اما نمی‌دونید دقیقاً کدوم سرویس یا کدوم کوئری دیتابیس داره وقت رو تلف می‌کنه…

اینجاست که قصه Zipkin شروع میشه.

🛠 Zipkin دقیقاً چیکار می‌کنه؟
زیپکین ابزارِ "Distributed Tracing" هست. یعنی چی؟ فرض کنید یه میکروسرویس دارید که برای گرفتن یه دیتای ساده، باید به ۳ تا سرویس دیگه درخواست بزنه، از اون طرف هم دیتابیسِ سرویس سوم کنده. پیدا کردنِ اینکه این وسط کجای این زنجیره، زمان هدر میره، بدون ابزار عملاً غیرممکنه.

زیپکین میاد برای هر درخواست یه Trace ID میسازه و تمامِ مسیرهایی که اون درخواست طی می‌کنه رو (از سرویس A به B، از B به دیتابیس و...) براتون مانیتور می‌کنه.

💡 مثال واقعی:
توی یک پروژه، ما یه سرویس “تخفیف” داشتیم که گاهی اوقات باعث می‌شد کل سبد خرید با تاخیر ۵ ثانیه‌ای لود بشه. وقتی لاگ‌ها رو چک می‌کردیم، همه سرویس‌ها می‌گفتن “ما اوکی هستیم”.
با Zipkin که مسیر رو نگاه کردیم، فهمیدیم مشکل از دیتابیس یا کد نیست؛ بلکه سرویسِ سبد خرید، برای چک کردنِ وضعیتِ هر آیتم، به جای اینکه یکبار به سرویسِ تخفیف درخواست بزنه، توی یک حلقه (Loop) به ازای هر محصولِ کاربر، یک ریکوئست HTTP جداگانه می‌فرستاد!

حالا اینجا یه سؤال پیش میاد…
آیا برای هر پروژه کوچیکی نیاز به Zipkin داریم؟ نه! این ابزار برای معماری‌های میکروسرویسی و سیستم‌هایی که پیچیدگی‌شون بالاست حکمِ طلا رو داره. اگر یه سرویسِ تکیِ ساده دارید، احتمالاً overkill محسوب میشه.

خلاصه ماجرا اینه که اگه می‌خواید توی سیستم‌های توزیع‌شده غرق نشید و دقیقاً بدونید هر میلی‌ثانیه زمان کجا صرف شده، Zipkin یکی از اون ابزارهاییه که باید توی جعبه‌ابزارتون داشته باشید.

اگر سوال یا تجربه‌ای درباره این موضوع دارید، به آی‌دی خصوصی من یا گروه پیام بدید؛ حتماً جواب می‌دیم.

#سامان #تکنولوژی
اگر این مطلب براتون مفید بود، با زدن روی تیک زیر پست اعلام حضور کنید ✅

⚠️ آدرس کانال در تلگرام( حتما جوین بشید )
🚀 @devsourcech
✅ در بله
🔹 Ch: @devsource
سایت مستندات برنامه نویسی:
🥇 https://devsource.ir