مخاطبین محترم کانال و گروه DevSource
میت آنلاین بذارم باهاتون؟
در مورد چه موضوعاتی دوست دارید صحبت کنیم و انتقال دانش داشته باشیم؟
یک میت دو ساعته


حتما توی کامنت ها نظرتونو بگید🚀

یک کتاب جمع و جور و کاربردی برای مبانی زبان طراحی سیستم ( Design system )

توسعه دهنده های فرانت اند بهتره که تسلط خوبی به مبانی دیزاین سیستم ها داشته باشند
احتمالا شنیدید که در اغلب فیلم ها٬ یه وقتایی وسط صحنه٬ بازیگرا با توجه به تجربه ای که دارن کارهای خلاقانه و فی البداهه انجام میدن

این موضوع در توسعه ی برنامه ها هم صدق میکنه٬ مخصوصا در فرانت اند. اگر یه وقتایی خواستید به عنوان توسعه دهنده ی فرانت اند خلاقیت به خرج بدید و فیچر جدیدی خارج از برنامه به رابط کاربری اضافه کنید٬ حتما باید استاندارد های طراحی رو بدونید تا یکپارچگی زبان طراحی سیستم از دست نره

منابع ذیل میتونه برای همین مواقع بهتون کمک کنه:
https://ebooks.karbust.me/Technology/UI%20Design%20Principles%20-%20Michael%20Filipiuk.pdf

https://designcode.io/ui-design-handbook

Reaction 👎👍 و Share

#سامان #مفاهیم

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

اعداد حیاتی که هر برنامه‌نویس باید بداند (Latency Numbers)

شاید برایتان سوال شده باشد که چرا گاهی اوقات یک سیستم با وجود سرورهای قدرتمند، همچنان کند عمل می‌کند؟
پاسخ اغلب در “تأخیر” (Latency) نهفته است. درک مقیاس زمانی عملیات کامپیوتری، تفاوت بین یک برنامه‌نویس معمولی و یک مهندس ارشد است.

دکتر دین (Dr. Jeff Dean) از گوگل جدولی از زمان‌بندی عملیات‌های پایه‌ای کامپیوتر ارائه کرده که با وجود گذشت سال‌ها، هنوز هم «انجیل» درک کارایی سیستم‌هاست. اگرچه سخت‌افزارها سریع‌تر شده‌اند، اما تفاوت مقیاس زمانی (مثلاً تفاوت بین حافظه کش و شبکه) هنوز هم به همان نسبت تکان‌دهنده است.

💡 سه درس کلیدی از این اعداد:
۱. حافظه از دیسک بسیار سریع‌تر است: تفاوت بین خواندن از رم و خواندن از دیسک مثل تفاوت یک چشم به هم زدن و چندین دقیقه زمان است.
۲. شبکه گران‌قیمت‌ترین عملیات است: هر بار که درخواستی به شبکه می‌فرستید، چندین مرتبه بزرگ‌تر از عملیات‌های داخل CPU هزینه زمانی می‌پردازید.
۳. بهینه‌سازی را از گلوگاه‌ها شروع کنید: تا زمانی که دیتابیس یا شبکه شما کند است، بهینه‌سازی کدهای ریاضی CPU تفاوت محسوسی در تجربه کاربری ایجاد نمی‌کند.

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

اینجاست که Cache وارد بازی می‌شود.

اگر اطلاعاتی مثل Session، Claims، Role یا نتیجه اعتبارسنجی Token را برای مدت کوتاهی Cache کنید، بخش بزرگی از درخواست‌ها دیگر نیازی به مراجعه به دیتابیس یا سرویس Identity ندارند. نتیجه کاملاً ملموس است:

✅ کاهش زمان پاسخگویی
✅ کاهش فشار روی دیتابیس
✅ افزایش توان پردازش سیستم
✅ تجربه کاربری بهتر

البته Cache در Authentication یک شمشیر دولبه است. اگر زمان انقضا (TTL) را درست انتخاب نکنید، ممکن است کاربری که دسترسی‌اش حذف شده، تا چند دقیقه همچنان بتواند از همان مجوزها استفاده کند.

به همین دلیل، طراحی Cache در Auth فقط برای افزایش سرعت نیست؛ باید بین Performance و Security تعادل برقرار کنید.

یک قانون ساده:
هر اطلاعاتی که امنیت بالایی دارد و ممکن است سریع تغییر کند، یا نباید Cache شود یا باید مدت نگهداری بسیار کوتاهی داشته باشد. یا در زمان ویرایش اطلاعات ، در Cache هم آپدیت شود.

سرعت مهم است، اما در سیستم‌های احراز هویت، امنیت همیشه اولویت اول است.

#Authentication #Authorization #Cache #Redis #Performance #Security #Backend #رادمان


🚀 Telegram: @devsourcech
🍂 Bale: @devsource

🤖 OpenAi and Hugging Face

برای اولین بار، OpenAI تأیید کرد که یک عامل هوش مصنوعی در حین تست امنیتی از محیط آزمایشی خارج شد و به زیرساخت Hugging Face نفوذ کرد.🔥

داخل ویدئو بیشتر توضیح داده شده توسط جادی عزیز♥️

#abolfazl #ai #OpenAi #HuggingFace

🚀 Telegram: @devsourcech
🍂 Bale: @devsource

در مورد Race condition خوب توضیح می‌ده ☘️

منبع

ممنون از هادی عزیز برای ارسال این پست✌️

#abolfazl #race_condition #database

🚀 Telegram: @devsourcech
🍂 Bale: @devsource

بعد از مدت ها سلام 😍
یه چیز جالب بگم؟
🐳 خیلی‌ها جداولشون رو طوری می‌نویسن که همیشه فیلد id از نوع عدد و به صورت AUTO_INCREMENT باشه.

تا حالا فکر کردید اگه به جای عدد از UUID توی فیلدهای primary استفاده کنید، چه مزیت‌هایی به دست میارید؟

خوب اولین چیزی که باید بگم اینه که AUTO_INCREMENT فقط وقتی راحت و تمیزه که یه سیستم خصوصی و دم دستی داشته باشی. همین که بخوای از چند جا رکورد بسازی، دیتا رو مرج کنی، یا حتی آفلاین ID تولید کنی، داستان عوض میشه.
UUID اینجا کمک می‌کنه چون ID رو مستقل از دیتابیس می‌سازی… بدون اینکه منتظر شماره بعدی بمونی.

⚠️ چند دلیل مهم که معمولاً باعث میشه UUID انتخاب بهتری باشه:
- می‌تونی ID رو سمت اپلیکیشن، سرویس، یا حتی کلاینت بسازی
- برای سیستم‌های توزیع‌شده، shard شده، یا چند دیتابیسی خیلی راحت‌تره
- موقع merge کردن دیتا از چند منبع، تداخل ID نداری
- شماره ردیف‌ها رو لو نمی‌دی و حدس زدن رکوردها برای هکر ها که میخوان با استفاده از URL دیتا رو استخراج کنند سخت‌تر میشه
- برای ساخت داده قبل از ذخیره‌سازی، وابستگی‌ات به دیتابیس کمتر میشه

حالا یه سؤال پیش میاد… پس چرا همه‌جا UUID نمی‌زنیم؟

اینجاست که باید واقع‌بین باشی. UUID توی جدول‌های بزرگ می‌تونه روی index فشار بیاره، مخصوصاً اگه نسخه‌های تصادفی مثل UUIDv4 استفاده کنی، چون درج‌ها پراکنده میشن و page split و fragmentation بیشتر میشه.
برای همین توی بعضی دیتابیس‌ها و سناریوها، AUTO_INCREMENT هنوز برای یه دیتابیس تک‌نویسنده، ساده‌تر و بهینه‌تره. حتی الان هم خیلی وقت‌ها برای سیستم‌های ساده، همون AUTO_INCREMENT بهترین انتخابه.

🚀 یه مثال واقعی: فرض کنید یه فروشگاه آنلاین دارید که سفارش‌هاش از وب‌سایت، اپ موبایل، و یه سرویس بک‌اند جدا ساخته می‌شن. اگر همه‌جا AUTO_INCREMENT داشته باشی، هماهنگ کردن شماره‌ها و merge کردن دیتا دردسر میشه. ولی با UUID هر سرویس همون لحظه ID خودش رو می‌سازه و بعداً بدون اصطکاک ذخیره‌اش می‌کنی.

خلاصه ماجرا اینه:
اگر سیستم‌ات ساده‌ست و فقط یه دیتابیس مرکزی داری، AUTO_INCREMENT هنوز انتخاب خوبیه.
اگر داری سمت معماری توزیع‌شده، چند سرویس، sync، merge، یا تولید ID مستقل می‌ری، UUID انتخاب منطقی‌تریه.

#سامان
#db
⚠️ آدرس کانال در تلگرام(حتما عضو بشید)
🚀 https://t.me/devsourcech
✅ در بله
🔹 @devsource
‌
سایت مستندات برنامه نویسی:
🥇 https://devsource.ir

عجب وضعیه 😂

کپشن: وایب کدینگ باعث شده اگه داخل گیت‌هاب OPENAI_API_KEY رو سرچ کنید، هزاران کلید رایگان به دست بیارید .

منبع

#abolfazl #ai

✅ Telegram: @devsourcech
⚠️ Bale: @devsource

سلام سلام
خیلی‌ها پروژه رو می‌برن تو پروداکشن، بعد از بازخورد های اولیه شروع می‌کنن به رفع باگ‌ها و کندی‌ها٬ چون محصول آرام آرام کاربران رو جذب میکنه …

این روش برای خیلی از محصول‌ها جواب می‌ده٬ تاکید میکنم ( برای خیییلی از محصولات جواب میده )

قطعا خیلی هاتون این چیزایی رو که در ادامه به صورت خلاصه مینویسم رو کاملا میدونید٬‌ اما برای جوون ترا و یادآوری خودم مینویسم:

اگر خدای چالش در خونتونو زد و یه پروژه ای دستتون افتاد که از روز اول معرفی خواست بره زیر دست تعداد زیادی کاربر چی؟

اگه از روز اول بخوایم خیال‌مون از پرفرمنس و پایداری یه همچین پروژه ای راحت‌تر باشه، باید قبل از پروداکشن به چی دقت کنیم؟

خلاصه ماجرا اینه که قبل از لانچ، باید هم بار واقعی رو شبیه‌سازی کنی، هم گلوگاه‌ها رو زود پیدا کنی، هم سطح حمله رو پایین نگه داری.

🚀 اول از همه، دیتای تست باید واقعی‌نما باشه

اگر دیتابیس فقط با ۵۰ تا رکورد تست بشه، خیلی از مشکل‌ها خودشون رو نشون نمی‌دن.

پس باید از همون اول یه دیتای ماک حجیم بسازی؛ مثلاً چند میلیون رکورد شبیه داده واقعی.
این کار کمک می‌کنه کوئری‌های سنگین، ایندکس‌های ضعیف، و گزارش‌های کند زودتر خودشون رو لو بدن.

مثلاً یه نرم‌افزار حسابداری رو تصور کن که فعلاً فقط با داده‌های کم تست شده.
همه‌چیز خوبه… تا روزی که یه گزارش ماهانه روی چند میلیون تراکنش اجرا می‌کنی و می‌بینی کل سیستم می‌خوابه.

⚙️ بعدش باید فضای تست شبیه پروداکشن داشته باشی

یعنی فقط اپ بالا نباشه؛
نسخه سرویس‌ها، تنظیمات، منابع، کش، صف، و حتی محدودیت‌ها هم تا حد ممکن شبیه محیط واقعی باشن.

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

🛡 امنیت رو از اول ببین، نه بعد از حادثه

اگر پروژه حساسه، از همون اول باید به چیزهایی مثل penetration test، محدودسازی دسترسی‌ها، و مانیتورینگ رفتار مشکوک فکر کنی.

یه هانی‌پات هم می‌تونه برای بعضی سناریوها مفید باشه؛ نه به‌عنوان بخش اصلی سیستم، بلکه به‌عنوان یه تله‌ی کنترل‌شده و جدا از مسیر اصلی که رفتار مهاجم رو ثبت کنه و ضعف‌ها رو زودتر نشون بده.
فقط باید کاملاً ایزوله، مانیتوردار، و بدون دیتای واقعی باشه.

🔍 گزارش‌های سنگین رو از دیتای لحظه‌ای نساز

خیلی از سیستم‌ها این اشتباه رو می‌کنن که گزارش‌گیری سنگین رو مستقیم روی دیتای transactional می‌چسبونن.

نتیجه؟
هم نوشتن داده کند می‌شه، هم خواندن.

پس باید از همون اول به جداسازی فکر کنی؛ مثلاً با CQRS، یا حداقل با read model جدا، snapshot، یا pipeline گزارش‌گیری مستقل.

📦 کش و rate limit رو جدی بگیر

اگر endpointها قراره زیاد خونده بشن، کش می‌تونه فشار رو خیلی کم کنه.
اما کش بدون invalidation درست، خودش یه دردسر جدید می‌شه.

از اون طرف rate limit هم فقط برای امنیت نیست؛ برای اینه که یه کلاینت بدرفتار یا یه job اشتباه کل سیستم رو زمین نزنه.

🧩 خلاصه اینکه قبل از پروداکشن همه ی شما و خودم را به چک کردن این موارد دعوت میکنم😅

✅ دیتای ماک حجیم برای تست کوئری‌ها
✅ محیط تست نزدیک به پروداکشن
✅ پنتست و بازبینی امنیتی
✅ هانی‌پات فقط در سناریوهای حساس و ایزوله
✅ جلوگیری از گزارش‌گیری سنگین روی دیتای لحظه‌ای
✅ فکر کردن به CQRS یا read/write separation
✅ کش درست و قابل کنترل
✅ rate limit برای محافظت از سرویس
✅ محاسبه ی منابع مورد نیاز در سرور٬ مخصوصا IOPS مناسب برای هارد
✅ بکاپ و DisAster recovery
✅ HA
✅ افزونگی منابع
✅ لودبالانس
✅ WAF
✅ SLA contract
✅ Release Life cycle
✅ ScaleAbility


خلاصه، اگر از اول این چیزها رو ببینی، خیلی کمتر مجبور می‌شی بعداً با آتش‌نشانی محصول رو سر پا نگه داری 🫣…

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


#سامان

✅ Telegram: @devsourcech
⚠️ Bale: @devsource
‌

سلام سلام
🚀 داستان از یه پیام ساده شروع میشه: «واسه این بخش یه دکمه هم بذار، سخت نیست که!»

یه لحظه به درخواستی که ازت کردند نگاه میکنی. سخت نیست، واقعاً هم نیست. نیم ساعت کاره. ولی وقتی انجامش میدی میبینی نصف روزت رو گرفته!!!

اینجاست که خیلیها اشتباه میکنن. بعضی جوگیر میشن و میگن «باشه، همین الان اضافش میکنم». بعضی هم جبهه میگیرن و از کوره در میرن. البته که هر دو اشتباهه.

حالا بذار یه چیز مهم بگم:

📌 درخواستِ خارج از قرارداد، نه تهدیده، نه لطف اضافه. یه فرصته. فقط باید بلد باشی چطوری باهاش رفتار کنی.

مشکل اینجاست که خیلی از برنامه نویسای فریلنسر یا پاره وقت، دوتا اشتباه رایج میکنن:
- یا خیلی چیزا رو رایگان قبول میکنن که کار قشنگ پیش بره
- یا با یه جواب سرد رد میکنن و اعتماد رو میسوزونن

بازم هر دو تا حالتهاشون اشتباهه. 😅

🔑 نکته مهم اینه: هر درخواست اضافه، یه «موقعیت»ه نه یه «تهدید». اگه با انعطاف برخورد کنی ولی مرز توقعات رو در سطح مناسب نگه داری، هم اعتماد میسازی، هم پول رو میگیری.

سؤال اینه: کی قبول کنیم، کی نه؟

✅ اولین فاکتورش حجم کاره. یه درخواست ده دقیقه ای که میتونه رابطه رو بهتر کنه — بده و ببخش. این سرمایه گذاریه، نه کار رایگان.

⚠️ ولی اگه قراره دو روز وقتت رو بگیره؟ اونوقت موقعیت فرق میکنه. این دیگه یک استوری جدید تو دل پروژهٔ قبلیه. اینجا اگه بهونه بیاری که «حواسم نبود»، باید به خاطر نداشتن مرز و چهارچوب، خودت رو مقصر بدونی و سعی کنی تو یه جای همیشگی یادداشتش کنی تا چهارچوب مناسب خودتو بسازی.

🧩 برگ برندهٔ اصلی تو اون اول کار ساخته میشه: قراردادی که توش دقیقاً نوشته بشه چیا داخل کاره و چیا نیست. به این میگن Scope of Work. حتی لیست کن چی داخل کار نیست! این یه کاغذ نیست. این سپر دفاعی و کیفی پروژه توئه.

خیلی ها فکر میکنن اگه بگن «این خارج از قرارداده»، مشتری ناراحت میشه.
ولی برعکس — مشتریِ خوب برای شفافیت احترام میذاره. اونی که نمیخواد چیزی رو مکتوب کنه، خودش یه زنگ خطره.

پس اگه درخواست اومد، به جای «نه» یا «باشه استاد»، از جواب «بله ولی...» استفاده کن:
«اوکی، قشنگه. ولی این خارج از چیزیه که توافق کردیم. یه برآورد جدا برات مینویسم، هم قیمتش رو هم تأثیرش روی تحویل رو. نظرتون چیه؟»

🔥 این دقیقاً همون لحظه ایه که هم حرفه ای به نظر میای، هم کار جدید رو از دست نمیدی. مشتری نمیخواد اذیتت کنه، فقط نمیدونه این نظری یا کاری که میخواد خارج از قرارداده.

چیکار کنیم عملاً؟

🧭 سه تا فاز داریم. فاز اول: اگه کار کوچیکه و مشتری قدیمیه، به عنوان حسن نیت انجام بده ولی تو ذهنت قایمش نکن. سر جلسهٔ بعدی آروم یادآوری کن چقدر اضافه کاری کردی. این یه سرمایه گذاری است، نه باخت.

🧭 فاز دوم: اگه کار متوسطه، با چند گزینه برگرد. نگو «نمیتونم». بگو: «این یه هفته وقت میخواد. دو راه داریم؛ یا بودجش رو اضافه کنیم، یا تحویل رو یک هفته عقب بندازیم. کدوم رو ترجیح میدی؟» انتخاب رو بذار دست مشتری.

🧭 فاز سوم: اگه درخواست بزرگه و مهلت عوض نمیشه؟ حالا دیگه قطعاً باید گفت وگوی جدی بشه. مودبانه ولی محکم. اگه مشتری از نوشتن جزئیات فرار میکنه، این خودش یه زنگ خطر قرمزه.

💡 نکته ای که خیلیا هنوز یاد نگرفتند: احترام به مشتری رو با «همیشه بله گفتن» نشون نمیدن. با شفافیت و قابل پیشبینی شدن امور هست که مشتری بهت اعتماد میکنه.


#سامان

✅ Telegram: @devsourcech
⚠️ Bale: @devsource

ديروز درباره قابليت Live Translate در Google AI Studio نوشتم؛ ابزارى كه با كمك مدل هاى جديد هوش مصنوعى مى تونه ترجمه صوتى لحظه اى انجام بده
پست قبلى
https://lnkd.in/d_gMDPjW
ولى مشكلى كه داشت اين بود كه سرعتش با اینترنت ما 😤 اره كند بود ...

وليبيى ابزار امروز سرعتش خيلى بهتره✅
اسمش LivDub هست، يك اكستنشن ساده كه با كمك AI میتونه
صداى ويديوهاى داخل مرورگر رو به زبان
دلخواه شما دوبله كنه

PostLink

ممنون میشم از این پست در لینکدین دیدن کنید🌹
#abolfazl

✅ Telegram: @devsourcech
⚠️ Bale: @devsource

🐳 ورود به پلتفرم‌ها وقتی لاگین نیستی، همیشه یه حس تکراری و خسته‌کننده داره…

هر بار ایمیل، هر بار پسورد، هر بار کد تایید٬ اما چه کنیم٬ نیاز به امنیت هم داریم

حالا چطوری یک توازن در راحتی در ورود و امنیت دو مرحله ای ایجاد کنیم؟

⚠️ اینجاست که Passkey وارد بازی میشه

خلاصه ماجرا اینه:
به‌جای اینکه کاربر یه رمز عبور حفظ کنه، با همون اثر انگشت، Face ID، یا PIN خود دستگاه وارد میشه.
کلید خصوصی روی گوشی یا لپ‌تاپ خود کاربر می‌مونه، سمت سرور هم فقط یه کلید عمومی ذخیره میشه.
یعنی حتی اگر دیتابیس لو بره، چیزی که بشه باهاش مستقیم لاگین کرد دست مهاجم نمی‌افته.

🚀 مزیت بزرگ Passkey اینه که فیشینگ‌پذیر نیست

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

یه مثال واقعی:
فرض کنید یه پنل مالی دارید که کاربر هر روز باید واردش بشه.
با پسورد و OTP، هم تیم پشتیبانی درگیر ریست پسورد میشه، هم کاربر از تایپ کردن کد خسته میشه.
ولی با Passkey، کاربر فقط یه تایید بیومتریک می‌زنه و وارد میشه… خیلی تمیزتر.
🔐 پس جمع‌بندی ساده اینه:

Passkey
- امنیت خیلی بهتر
- تجربه کاربری خیلی روان
- مناسب برای محصولاتی که می‌خوای حرفه‌ای و مدرن باشن
- ولی باید Recovery درست‌وحسابی داشته باشی، چون اگه کاربر دستگاهش رو از دست بده، نباید قفل بشه

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

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


#سامان

⚠️ آدرس کانال در تلگرام(حتما عضو بشید)
🚀 https://t.me/devsourcech
✅ در بله
🔹 @devsource

معرفی سایت داریم 😍
https://freebuff.com

بیاید یه نگاه به Freebuff بندازیم…
یه سایت که ادعاش خیلی ساده‌ست: «کدنویسی رو ۱۰۰٪ رایگان می‌کنیم» و هزینه‌اش رو هم از تبلیغات درمیاره

Freebuff روی سایتش نشون می‌ده که برای یه تیم ۵ نفره، مدل‌های پولی می‌تونن چند هزار دلار در سال خرج بتراشن… بعد می‌گه من صفر دلار هستم
🚀 حالا این سایت فقط یه چت ساده نیست. از روی خود سایت چند تا محصول جدا داره:

- Freebuff Desktop
برای ویندوز، مک و لینوکس. نکته جالبش اینه که می‌گه می‌تونی چند تا coding agent رو همزمان روی سیستم خودت اجرا کنی، هر کدوم توی workspace خودش

- Freebuff CLI
یه ایجنت کدنویسی رایگان داخل ترمینال.

- Freebuff Web
یه ابزار ساخت وب‌اپ با AI که از prompt تا اپ زنده روی URL خودش می‌رسه

- Freebuff Cloud
یه cloud IDE کامل با editor، terminal و sandbox
می‌گه فقط به GitHub وصل می‌شی، public یا private repo فرقی نداره، و بدون نصب چیزی می‌تونی روی ریپو کار کنی
برای تیم‌هایی که نمی‌خوان محیط لوکال بسازن یا درگیر setup بشن، این خیلی جذابه

#سامان
✅ Telegram: @devsourcech
⚠️ Bale: @devsource

معرفی ابزار😍
https://worldmonitor.app

تا حالا شده یه خبر اقتصادی منتشر بشه و تا بخوای بری تحلیلش کنی، بازار حرکتش رو کرده باشه؟

این روزا خبرها و رخدادها بازارها رو جابجا میکنند.
اقتصاد روایی (Narrative Economics) یعنی همون چیزی که پشت پرده‌ست و بازارها رو جابه‌جا می‌کنه. چند وقت پیش دنبال یه ابزار بودم که بتونم این همبستگی‌ها رو به‌صورت لحظه‌ای ببینم تا به پروژه WorldMonitor برخوردم.

WorldMonitor میاد به جای خوندن اخبار، سیگنال‌های خام رو از دل دنیای واقعی می‌کشه بیرون؛ از حرکت کشتی‌ها و وضعیت کابل‌های زیردریایی گرفته تا مسیر پروازها و نوسانات انرژی.

📊 نکته جذابش اینه که یه موتور همبستگی (Correlation Engine) داره. مثلاً اگه یه تنش ژئوپلیتیک تو یه منطقه خاص اتفاق بیفته، بهتون نشون میده که این موضوع دقیقاً کدوم مسیرهای تجاری، قیمت کدوم کالاها یا وضعیت کدوم ارزها رو ممکنه تحت تأثیر قرار بده. این دقیقاً همون چیزیه که یه تریدر یا تحلیلگر داده برای درک درستِ جریانِ پول بهش نیاز داره.


#سامان

✅ Telegram: @devsourcech
⚠️ Bale: @devsource

چطور استاندارد ها به تشخیص محتوای اصلی کمک میکنند؟
تا به حال از خودتون پرسیدید٬ چطور سامانه ها٬ محتوای چندرسانه ای ساخته شده با هوش مصنوعی رو تشخیص میدن؟

خیلی‌ها فکر می‌کنن یه مدل AI فقط با نگاه کردن به عکس یا ویدیو و تحلیل تصویر می‌فهمه اصل هست یا نه
ولی در اغلب موارد این‌طوری نیست. پای استاندارهایی نظیر C2PA وسطه

(( Content Credentials (C2PA) یک برچسب آشکارکننده دستکاری روی یک تصویر است ))

یک عکاس از منظره ای عکس میگیره، اون عکس میره برای ویرایش، انتشار، و بازنشر در چند پلتفرم.
بدون استاندارد، هر کسی می‌تونه ادعا کنه این فایل اصلیه. ولی با C2PA، فایل یه زنجیره provenance داره؛ یعنی سامانه‌ها می‌تونن بررسی کنن این محتوا واقعاً از مسیر معتبر اومده یا نه.

بنیاد ContentCredential که استاندارد C2PA رو راهبری میکنه٬ متشکل از بیش از ۵۰۰ شرکت مطرح دنیا مثل ادوبی٬ مایکروسافت٬ گوگل٬ اوپن ای آی و ... هست که روزانه ۴۰۰ کیوینتیلیون (بنویسید ۱۰ به توان ۱۸) تصویر رو برچسب گذاری میکنند

#سامان #استاندارد

✅ Telegram: @devsourcech
⚠️ Bale: @devsource