WebBaz | وب باز
1.17K subscribers
732 photos
134 videos
81 files
650 links
قراره هرچیزی که نیازه و قراره توی پروژه واقعی به کار گرفته بشه رو یاد بگیریم

من: @call_me_nouh
لینکدین من : https://www.linkedin.com/in/mahdi-nouri-7aa043227
Download Telegram
جدی جدی حافظ دقیقا زد به هدف

هم آدم شدیداً رکی ام هم آدم شدیداً دهن لق 😂
و از اونجایی که به علم آمار بیشتر از علم فال و اینجور چیزا اعتقاد دارم خواستم ثابت کنم که اینا همش احتمالاته و روانشناسی.

دوباره رفتم فال بگیرم


حافظ زد توی دهنم 😑😑😑
گفت بجای این مسخره بازیا برو به کارات برس (الان منتظر ی نفرم که بیاد کارا رو شروع کنیم)
Pyhthonthonthonthon
MhrCode
اینم یه موزیک نمونه که دیس پایتون رو میدیم توش :))
🤣2🤔1
سیستم کند است؟ این ۴ عدد دروغ نمی‌گویند

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

در این پُست به چهار متریک بنیادی می‌پردازیم که شناخت آن‌ها برای هر مهندس نرم‌افزار ضروری است.

1- معیار Queries Per Second (QPS)
این معیار نشان می‌دهد سیستم شما در هر ثانیه چند درخواست ورودی دریافت می‌کند.
برای مثال، اگر سرور در یک ثانیه ۱۰۰۰ درخواست دریافت کند، مقدار QPS برابر با ۱۰۰۰ خواهد بود.
در نگاه اول، QPS متریکی ساده به نظر می‌رسد، اما چالش اصلی در پایداری آن نهفته است. بسیاری از سیستم‌ها قادر به حفظ QPS بالا در بازه‌های زمانی طولانی نیستند و در شرایط فشار، به‌تدریج دچار افت عملکرد می‌شوند.

2- معیار Transactions Per Second (TPS)
این معیار تعداد تراکنش‌های کاملاً انجام‌شده در هر ثانیه را نشان می‌دهد.
یک تراکنش شامل کل مسیر پردازش درخواست است؛ از دریافت درخواست تا تعامل با دیتابیس و بازگشت پاسخ نهایی.
برخلاف QPS که صرفاً تعداد درخواست‌های ورودی را نشان می‌دهد، TPS بیانگر میزان کار واقعی انجام‌شده است و معمولاً مهم‌ترین متریک از دیدگاه کسب‌وکار محسوب می‌شود.

3- معیار Concurrency (همزمانی)
این معیار تعداد درخواست‌های فعالی است که سیستم در یک لحظه در حال پردازش آن‌هاست.
برای مثال، ممکن است سیستم ۱۰۰ درخواست در ثانیه دریافت کند، اما اگر پردازش هر درخواست ۵ ثانیه طول بکشد، در عمل با ۵۰۰ درخواست همزمان مواجه خواهیم بود.
همزمانی بالا به معنای نیاز به مدیریت بهینه‌تر منابع، connection pool مناسب و کنترل دقیق‌تر threadها است.

4- معیار Response Time
این معیار مدت زمانی است که از آغاز یک درخواست تا دریافت پاسخ نهایی سپری می‌شود.
این متریک هم در سطح کلاینت و هم در سطح سرور اندازه‌گیری می‌شود و نقش کلیدی در تجربه کاربری و توان پردازشی سیستم دارد.

رابطه بین متریک‌ها:
این چهار متریک به‌طور مستقل عمل نمی‌کنند و رابطه‌ی مشخصی میان آن‌ها وجود دارد:
QPS = Concurrency ÷ Average Response Time
بر اساس این رابطه، افزایش همزمانی یا کاهش میانگین زمان پاسخ، منجر به افزایش توان پردازشی (Throughput) سیستم می‌شود.

تحلیل صحیح عملکرد سیستم بدون درک دقیق این متریک‌ها ممکن نیست.

@DevTwitter | <Amir Rahimi Nejad/>
Forwarded from  (امیرحسین پناهےفر)
بیشتر چیز هایی که امروز به اسم network programming میشناسیم، ریشه‌ شون برمیگرده به 4.2BSD جایی که برای اولین بار شبکه به عنوان یک مفهوم خیلی آشنا دیده شد. ایده این بود که اگه بتونی با فایل حرف بزنی، باید بتونی با شبکه هم دقیقاً به همون شکل حرف بزنی. همین نگاه ساده باعث شد read و write بشن هسته‌ ارتباطات شبکه ای در یونیکس.

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

بعد از اون باید به این اندپوینت هویت بدی. اینجاست که ساختار sockaddr_in میاد وسط وقتی میگی IPv4 هست، پورت 8081 رو میخوام و روی همه‌ اینترفیس‌ ها گوش بده، در واقع داری به کرنل میگی این فایل قراره نماینده‌ کدوم نقطه از شبکه باشه. با ()bind این هویت به سوکت چسبونده میشه. هنوز هیچ ارتباطی وجود نداره، فقط آدرس رزرو شده.

تا اینجا سوکت فقط میدونه کیه، نه اینکه چه کاری باید بکنه. ()listen دقیقاً همین‌ جا معنی پیدا میکنه با این فراخوانی، سوکت از حالت عادی خارج میشه و وارد حالت گوش دادن میشه. یعنی کرنل شروع میکنه به گرفتن SYN ها، صف اتصال درست میکنه و آماده میشه برای اینکه کسی واقعاً وصل بشه. این لحظه‌ ایه که برنامه از «یه فایل معمولی» تبدیل میشه به «یه سرور»

وقتی کلاینتی وصل میشه، ()accept صدا زده میشه. نکته‌ خیلی مهم اینه که ()accept همون سوکت قبلی رو برنمیگردونه. یک file descriptor جدید ساخته میشه که نماینده‌ی دقیقاً همون اتصال مشخصه. سوکت اصلی همچنان فقط گوش میده. این جدا شدن listening socket از connected socket یکی از پایه‌ای ترین مفاهیم TCP server هاس و خیلی‌ ها دقیقاً همین‌ جا گیج میشن نمیدونن...

از این به بعد دیگه هیچ چیز خاصی وجود نداره. ارتباط برقرار شده و فقط با یک file descriptor در ارتباطی ()read میکنی دیتا میاد. ()write میکنی دیتا میره. نه تابع خاص شبکه، نه تفاوت مفهومی با فایل. همون چیزی که 4.2BSD کانسپتش رو از اول میخواست همینه

سمت کلاینت هم داستان کوتاه‌ تره ولی همون استراکچر رو داره. ()socket ساخته میشه، با ()connect به یک آدرس مشخص وصل میشه، و بعدش همه‌ چیز دوباره به read و write ختم میشه. ()connect در واقع فقط handshake TCP رو کامل میکنه و به اون file descriptor معنی اتصال میده همین.

جذابش رو ما تو لینوکس epoll رو داریم که حالا بماند برای بحث آینده. :)
Forwarded from 🎄 یک برنامه نویس تنبل (Lazy 🌱)
🔶 ریال جدید و قران رسما به اقتصاد ایران آمد

درپی تصویب حذف صفر از پول ملی و لازم‌الاجرا شدن آن از اسفند ماه، لایحه بودجه ۱۴۰۵ نیز با ریال جدید بسته شده است.

انتظار می‌رود سال آینده بازارهای پولی و مالی وارد فضای جدیدی شوند و اسکناس‌های چاپ جدید هم کم‌کم روانه بازار شود تا طی یک پروسه پنج ساله، واحد پولی جدید در اقتصاد کشور حاکم شود.

گفتنی است طبق روال قبلی(ریال قدیم) رقم بودجه ۱۴۴ هزار میلیارد و ۴۱۴ میلیون و ۱۷۵ هزار و ۵۶ ریال محاسبه خواهد شد، اما بر اساس لایحه بودجه ۱۴۰۵ که با ریال جدید (حذف چهار صفر) آمده ۱۴ هزار و ۴۴۱ میلیارد و ۴۱۷ میلیون و ۵۰۵ هزار و ۶۰۰ ریال است.

در سیستم جدید، هر یک ریال جدید برابر با هزار تومان و هر ۱۰۰ قِران برابر با یک ریال است. این در حالیست که پیشتر بودجه با ریال قدیم (هر ١٠ هزار ریال برابر با یک هزار تومان) نگاشته می‌شد.

#خبر

@TheRaymondDev
👍1
یه ابزار/ریپوی خیلی کاربردی از مایکروسافت: Microsoft Learn MCP Server
اگه از Claude / Cursor / Copilot / Codex و… استفاده می‌کنید و «hallucination» و یا کدهای غیرقابل‌کامپایل (قدیمی) اذیتتون میکنه، این MCP Server، ایجنتتون رو مستقیم وصل می‌کنه به
آخرین داکیومنت رسمی Microsoft
نمونه‌کدهای Microsoft Learn

نصب سریع، رایگان، و بدون API Key.

https://github.com/microsoftdocs/mcp

@DevTwitter | <Amir Pournasserian/>
Forwarded from Linuxor ?
دیگه نیازی نیست کاربران رو مجبور کنیم مسیرِ طراحی‌شدهٔ ما رو طی کنن.

با Tambo، یک Generative UI SDK برای React، رابط کاربری واقعاً تطبیق‌پذیر می‌شه:
کاربر می‌گه چی می‌خواد و AI، با تکیه بر Zod schemas، دقیقاً همون کامپوننت رو رندر می‌کنه.

https://github.com/tambo-ai/tambo

@DevTwitter | <پروفشیونال/>
Forwarded from tech-afternoon (Amin Mesbahi)
در مورد این نظرسنجی، من گزینه‌هایی رو انتخاب کردم که به نحوی به هم مرتبط باشن و انتخاب «بزرگ‌ترین» چالش رو کمی به سمت بیان نحوه‌ی تحلیل مسئولیت‌ها ببره 😅

چهار عامل بین گزینه‌ها بود که ساده‌شده‌اش می‌شه:
- کارشناس
- مدیر
- حاکم
- محیط

حاکم فضایی ایجاد کرده که محیط غیر رقابتی، بدون چشم‌انداز و ثبات، جدا افتاده از جهان؛ مدیرها رو به حال خودشون رها کنه که نه در اثر تعامل با جهان آموزش ببینن، نه نیازی به پرورش کارشناس و جانشین‌پروری حس کنن؛ نه لزومی به برنامه‌ریزی میان|بلند مدت ببینن، نه احساس خطری برای سازمان‌سازی غیرمولد و تولید محصولات بی‌کیفیت!

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

💡 ولی رکن چهارم که توی توصیف بالا از هر سه عامل متأثره چی؟

یعنی کارشناسی که مدیر نالایق، و سازمانی که ساختار نامناسب داره رو تجربه می‌کنه؛ پرورش داده نمی‌شه تا مدیر خوبی بشه؛ در فضایی تنفس می‌کنه که حتی عبارت «تنفس» با توجه به آلودگی هوا طنزی تلخ به شمار می‌ره، هر روز شاهد بی‌ارزش‌تر شدن دستمزدش می‌شه، برای ساده‌ترین دسترسی به اینترنت باید صد جور سختی رو طی کنه و در یک فضای غیررقابتی هر چی تولید کنه، خریدار داره!

قضاوت من با ۱۱۹ نفری که بزرگ‌ترین چالش رو خارج از کارشناس دیدن، همسو است؛ ولی با یک تفاوت مهم!

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

بخشی از بدنه کارشناسی » وارد لایه مدیریتی می‌شن » بخشی از همین مدیران وارد بخش حاکمیتی می‌شن و محیط رو می‌سازن!
حالا سوال اینه: چرا کارشناسان ضعیف به مدیران ضعیف تبدیل می‌شن؟

اینجا دو تا سناریو داریم:

سناریو ۱، خوش‌بینانه: کارشناس قوی وارد مدیریت می‌شه ولی سیستم اون رو می‌بلعه. فشارهای سازمانی، فقدان حمایت، سیاست‌ورزی، و ساختارهای فاسد مجبورش می‌کنن یا سازش کنه یا بره. در این صورت مشکل ۱۰۰٪ ساختاری‌ست و ۹۴٪ نظرسنجی کاملاً درست.

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

نکته اساسی اینه که وقتی می‌گم کارشناس چالشه، منظورم سرزنش کردن قربانی نیست. کارشناس هم قربانی این سیستمه، هم بدون اراده و آگاهی، بازتولیدکننده اون!

چرا؟
۱. سیستم آموزشی فاجعه است » دانشجو با مهارت‌های تاریخ‌گذشته یا ناکارآمد فارغ‌التحصیل می‌شه
۲. فرصت یادگیری واقعی وجود نداره » شرکت‌ها روی رشد مهارت‌‌ها سرمایه‌گذاری نمی‌کنن
۳. شایسته‌سالاری نیست » کارشناس خوب پاداش نمی‌بینه، پس انگیزه از بین می‌ره
۴. فقر اقتصادی » کارشناس مجبوره توی حالت تلاش برای بقا کار کنه، نه حالت رشد

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

پس چرا می‌گم کارشناس چالش بزرگه؟

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

چرا؟
۱. منتظر نشستن برای اصلاح حاکمیت = بی‌نهایت
اگر بخواهیم حاکمیت عوض بشه تا محیط بهتر بشه تا مدیران بهتر بشن تا کارشناسان رشد کنن، این ۵۰ سال طول می‌کشه (اگه اتفاق بیفته).

۲. کارشناس تنها لایه‌ایه که می‌تونه از پایین فشار بیاره
حاکمیت و مدیریت ضعیف وقتی می‌ترسن که جایگزین‌های قوی‌تر ببینن. اگر ۱۰٪ کارشناسان exceptional باشن، فشار ایجاد می‌کنن.

۳. در بخش خصوصی، عاملیت فردی واقعاً کار می‌کنه
دیوار، دیجیکالا، کافه‌بازار و.. همه توسط افرادی ساخته شدن که برای دریافت مجوز معصل نبودن! بله، شانس و زمانه دخیل بود، ولی اگر «قابلیت» نبود، هیچ‌کدوم موفق نمی‌شدن.
این به معنی گذاشتن تمام بار روی دوش کارشناس نیست. ما باید بین تشخیص و تجویز فرق بگذاریم:
تشخیص: لایه کارشناسی گلوگاه بحرانیه
تجویز: نه اینکه "کارشناس باید فقط تلاش کنه"، بلکه اینکه:

- باید یادگیری جمعی ایجاد شه
- و peer accountability شکل بگیره (اشتراک دانش و تجربه واقعی)
- استانداردهای خودِ ما بالا بره (قبول نکردن شرایط زیر خط قرمز)
- بهترین‌ها صدای خودشون رو بلند کنن و الگو باشن

این کافیه؟ قطعاً نه.
بدون این، چیز دیگه‌ای کافیه؟ باز هم نه.

در متن سوال نظرسنجی نوشتم بزرگ‌ترین چالش، و نه مقصرترین؛ چون چالش یعنی سخت‌ترین مانع برای عبور به آینده بهتر؛ حتی اگر ریشه اون در جای دیگه‌ای باشه.

نظر و تحلیل شما چیه؟
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Shayan GeeDook🐧
درود عزیزان
با توجه به اینترنت و شرایط بدی که ممکنه پیش بیاد و به مشکل میرور خوردید هرجایی، ما سعی داریم منابع این رپو رو اپدیت کنیم و میتونید تست کنید و حتما سیو کنید ممکنه بدردتون بخوره. اگر هم تونستید مشارکت کنید که من خیلی خوشحال میشم
https://github.com/GeeDook/mirava

@shayangeedook
❤‍🔥1
Forwarded from DeepMind AI Expert (Farzad 🦅)
پیتر تیل سال ٢٠١٢ یه کلاس در استنفورد برگزار کرد که درش تعداد زیادی از افراد معروف سیلیکون ولی مثل سم آلتمن و مارک اندریسن در مورد #استارتاپ و جوانب مختلفش صحبت کردن. سری ویدیوهاش اینجاس.
#منابع #کلاس_آموزشی

https://youtube.com/playlist?list=PLU630Cd0ZQCMeQiSvU7DJmDJDitdE7m7r&si=iq8kr7O-0_qrMSZe

🔹 مطالب بیشتر 👇👇

@AI_DeepMind
🔸 @AI_Person
Please open Telegram to view this post
VIEW IN TELEGRAM
مهارتهای شما چقدر مورد تقاضا هستند و خواهند بود؟
https://linkedin.com/feed/update/urn:li:groupPost:138801-7408367253890650112

@DevTwitter | <Mehdi/>
Forwarded from CodeCrafters (Behzad Azadi)
یکی از بچه‌ها تو‌گروه راجب باگ، تست و مدیریت فنی پرسید، یه پست کوتاه راجبش بزارم

اول از همه باید این واقعیت را بپذیریم:
باگ بخشی اجتناب‌ناپذیر از توسعه نرم‌افزار است.
بنابراین بهتر است با آن برخورد احساسی یا تنبیهی نداشته باشیم.

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

در موارد نادر، ریشه‌ی باگ می‌تواند به تخصیص نادرست تسک (عدم تناسب سطح تسک با توان نیروی انسانی) برگردد.

سطح‌بندی باگ‌ها
باگ‌ها در سطوح مختلفی قرار می‌گیرند:
در سطوح Critical / Blocker باگ‌های واقعاً بحرانی و متوقف‌کننده

سایر موارد معمولاً در دسته‌ی Issue قرار می‌گیرند


نکته‌ی مهم اینجاست:
همه‌ی باگ‌ها لزوماً بد یا مخرب نیستند.

بدهی فنی، تهدید یا فرصت؟
در واقع Issueها و باگ‌های غیر بحرانی تا یک سطح مشخص، مصداقی از چیزی هستند که به آن می‌گوییم:
Technical Debt (بدهی فنی)


البته بدهی فنی فقط باگ نیست و می‌تواند شامل:
* طراحی غیر بهینه
* تصمیم‌های کوتاه‌مدت معماری
* تست‌نویسی ناکافی
* پیچیدگی‌های انباشته‌شده‌ی سیستم باشد.

اما بخشی از بدهی فنی می‌تواند خودش را به‌صورت باگ یا Issue نشان دهد.

بدهی فنی تا سطح متوسط:
باعث افزایش دانسته‌ی سازمانی (افزایش دانش فنی) می‌شود
تجربه‌ی تیم را بالا می‌برد
و یکی از نشانه‌های بلوغ فنی سازمان محسوب می‌شود
(این مفهوم به‌صورت انتزاعی با شاخص‌هایی مثل TRL / TRA هم‌راستاست)


حد قابل‌قبول بدهی فنی چگونه سنجیده می‌شود؟
به‌صورت تجربی و مدیریتی (نه الزاماً آکادمیک)،
می‌توان از این معیار استفاده کرد:

زمان مورد نیاز (مقدار روز یا ساعت) برای رفع باگ و Issue تقسیم بر زمان کل توسعه (مقدار روز یا ساعت) ضرب در صد (که درصد به دست بیاریم)
حالا خروجی بالا؛
کمتر از ۱۵ درصد موجب دانسته (افزایش دانش فنی) میشه

تا ۳۰ درصد یعنی پروژه در لبه بحران هستش

و بیشتر از ۳۰ درصد نیاز به بازنگری جدی در فرآیند توسعه (اسکرام یا معادل آن) و تصمیم مدیریتی وجود دارد
(ادامه با هزینه، یا توقف/بازطراحی پروژه)


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

(اینم اضافه کنم نیروی بیش از حد شلوغ هم ضد معیار TRA/TRL هستش یعنی سازمان یک ایرادی داره)

چطور می‌توان تولید باگ را کاهش داد؟
برخلاف تصور رایج

فلوچارت و تحلیل جریان کار، در بسیاری از موارد حتی از تست‌نویسی مؤثرتر است


اکثر باگ‌ها ناشی از:
- نبود تصویر ذهنی شفاف
- مشخص نبودن مسیرها و حالت‌ها
- بی‌دقتی در سناریوها
هستند
+ نه کمبود دانش فنی

قبل از کدنویسی:
- فلوچارت بکشید
- سناریوها را مرور کنید
- و Design Review انجام دهید
+سپس کدنویسی و تست را شروع کنید


با تشکر از هوش مصنوعی که متنم رو‌ مرتب کرد (باورکنید فقط مرتبش کرد اه)

@code_crafters
Media is too big
VIEW IN TELEGRAM
یک وب‌اپلیکیشن برای Gemini File Search ساختم که میتونید روی سیستم شخصیتون اجراش کنید و ازش استفاده کنید.
فایل‌سرچ یکی از محصولات جدید و بسیار کاربردی جمنایه که کل مکانیزم RAG رو براتون ساده و اتوماتیک انجام میده. میتونید فضاهای مختلفی رو داخلش بسازید و داخل هرکدوم کلی داکیومنت، کد و ... قرار بدید و بعد با کمک گوگل، با دقت بالایی با تمام اون دیتا چت کنید.
فقط یک بدی داشت اونهم اینکه UI نداشت و فقط با کد کار میکرد که من اینجا سعی کردم اون رو حل کنم.
این لینک گیت‌هاب:
https://github.com/aminanvary/Gemini-File-Search
ویدیوی پایین هم برای توضیح اینکه جمنای فایل سرچ دقیقا چیه، مزیتش چیه و چطور از این وب‌اپ کوچیک استفاده کنید

@DevTwitter | <Amin Anvary/>
🔥1
اوپن‌ای‌آی یه مجموعه تازه از «پرامپت پک‌ها» منتشر کرده. این مجموعه شامل بیش از ۳۰۰ پرامپت آماده و تخصصیه که برای شغل‌ها و نقش‌های مختلف حرفه‌ای طراحی شدن
https://academy.openai.com/public/tags/prompt-packs-6849a0f98c613939acef841c

@DevTwitter | <محمد زمانی/>
Forwarded from WrongBug☕️
Forwarded from WrongBug☕️