دیشب با امین جان مصباحی یه جلسه خیلی مفید داشتیم و قرار شد یه جلسه ست کنیم و در مورد برنامه هامون در جهت رشد برای سال آینده گفت و گو کنیم و به سوالات افراد علاقه مند پاسخ بدیم.
من خودم خیلی هیجان زده این جلسه هستم. گوش به زنگ باشید برای اعلام روز و ساعتش.
قطعا قراره بهمون خوش بگذره.
من خودم خیلی هیجان زده این جلسه هستم. گوش به زنگ باشید برای اعلام روز و ساعتش.
قطعا قراره بهمون خوش بگذره.
Telegram
tech-afternoon
تِک‌افترنون، رویدادی گاه‌به‌گاه است با موضوعات حول معماری و توسعه نرم‌افزار، این کانال هم برای اشتراک اخبار، آموزش، نکاتی حول مهندسی نرم‌افزار، دیتابیس، تکنولوژی و مدیریت تولید محصولات نرمافزاری خواهد بود.
youtube.com/@AminTechTalks/videos
امین مصباحی
youtube.com/@AminTechTalks/videos
امین مصباحی
😍14🔥1🤔1
#معرفی_کتاب
The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece
یک کتاب عالی برای درک سادگی در نرم افزار.
چیزی که این روز های خیلی دیده میشه، تولید نرم افزار هایی بسیار پیچیده در استفاده توسط کاربر، نگهداری و توسعه است.
دلایل زیادی برای این امر وجود داره که یکی از اونها اشتباه گرفتن سادگی با کم کاربرد بودن هست.
عمیقا اعتقاد دارم که ساده بودن بسیار کار سخت تری از پیچیده بودن هست و شما انرژی زیادی برای ساده بودن(در هر زمینه ای) باید خرج کنید.
این کتاب که توسط رون جفریز(یکی از امضا کنندگان بیانیه چابکی) نوشته شده یک کتاب بسیار جذاب برای افرادی هست که علاقه دارند سادگی در نرم افزار رو جایگزین پیچیدگی کنن.
این کتاب رو به تمام سطوح مهندسی پیشنهاد می کنم.
برای دانلود می تونید از این آدرس استفاده کنید :
https://refhub.ir/refrence_detail/the-nature-of-software-development-keep-it-simple-make-it-valuable-build-it-piece-by-piece/
The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece
یک کتاب عالی برای درک سادگی در نرم افزار.
چیزی که این روز های خیلی دیده میشه، تولید نرم افزار هایی بسیار پیچیده در استفاده توسط کاربر، نگهداری و توسعه است.
دلایل زیادی برای این امر وجود داره که یکی از اونها اشتباه گرفتن سادگی با کم کاربرد بودن هست.
عمیقا اعتقاد دارم که ساده بودن بسیار کار سخت تری از پیچیده بودن هست و شما انرژی زیادی برای ساده بودن(در هر زمینه ای) باید خرج کنید.
این کتاب که توسط رون جفریز(یکی از امضا کنندگان بیانیه چابکی) نوشته شده یک کتاب بسیار جذاب برای افرادی هست که علاقه دارند سادگی در نرم افزار رو جایگزین پیچیدگی کنن.
این کتاب رو به تمام سطوح مهندسی پیشنهاد می کنم.
برای دانلود می تونید از این آدرس استفاده کنید :
https://refhub.ir/refrence_detail/the-nature-of-software-development-keep-it-simple-make-it-valuable-build-it-piece-by-piece/
👍10❤3🔥2
Forwarded from سماموس: نوشته‌های یوسف مهرداد بی‌بالان (Yousef Mehrdad)
قانون هایروم (Hyrum’s Law)-بخش اول
طی چند سال گذشته و به دلیل همکاری‌ام برای انتقال (migration) زیرساخت‌های سطح پایین یکی از پیچیده‌ترین سیستم‌های نرمافزاری روی کره‌ی خاکی به نکات مهمی درباره‌ی تفاوت بین رابط (interface) و پیاده‌سازی آن (implementation) برخورد کرده‌ام. معمولن ما رابط (interface) را تجریدی (abstraction) برای ارتباط با سیستم میدانیم و پیاده‌سازی (implementation) را هم روشی میدانیم که سیستم کارش را انجام می‌دهد. برای نمونه فرمان و پدال‌های گاز و ترمز در خودرو مانند رابط عمل می‌کنند و چرخ‌ها و موتور هم مانند پیاده‌سازی هستند (ارتباط ما با خودرو از طریق فرمان و پدال‌ها است ولی خودرو به کمک موتور و چرخ‌ها کار خواسته‌شده را انجام می‌دهد). چنین مفهومی به دلایل متعددی مفید است که مهم‌ترین‌اش این است که پیچیدگی بسیاری از سیستم‌های پرکاربرد خیلی سریع به حدی می‌رسد که فهم و شناخت کامل آن برای یک فرد یا گروه دشوار می‌گردد و تجرید‌ها (abstraction) برای مدیریت این پیچیدگی بسیار مهم و حیاتی‌اند.
تعریف سطح درستِ تجرید (abstraction)، موضوع کاملن جداگانه‌ای است که در اینجا به آن نمی‌پردازیم (کتاب نفر ماه افسانه‌ای -Mythical Man-Month- را ببینید). نکته مهم این است که وقتی یک تجرید (abstraction) تعریف شد ما دوست داریم آن را غیرقابل تغییر، شفاف و تفسیرناپذیر بدانیم. به عبارت دیگر، هر رابط (interface) از دیدگاه نظری باید مرز شفافی بین استفاده‌کنندگان یک سیستم و پیاده‌سازی داخلی سیستم ترسیم کند. اما از دیدگاه عملی، با رشد تعداد استفاده‌کنندگان و استفاده از سیستم، این نظریه نقض می‌شود و استفاده‌کنندگان شروع به اعتماد و اتکا به جزییات پیاده‌سازی می‌کنند. این جزییات یا دانسته از طریق رابط (interface) به بیرون درز کرده یا خود استفاده‌کنندگان موقع استفاده از سیستم آنها را کشف کرده و فهمیده‌اند. «قانون تجریدهای دارای نشتی اسپولسکی» (Spolsky’s Law of Leaky Abstractions) توضیح می‌دهد که چگونه استفاده‌کنندگان به جزییات پیاده‌سازی اعتماد و اتکا می‌کنند.
نهایت چنین اتفاقی ما را به سوی مفهومی هدایت می‌کند که در محاوره به آن «قانون رابط‌های ضمنی یا غیرشفاف» (The Law of Implicit Interfaces) گفته می‌شود: با فرض وجود تعداد کافی از استفاده‌کنندگان، چیزی به نام پیاده‌سازی خصوصی (private implementation) وجود ندارد [پیاده‌سازی خصوصی به این معناست که استفاده‌کننده هیچ اطلاعی از نحوه و روش پیاده‌سازی داخلی سیستم ندارند].
گزیده:
وقتی داشتم این کد رو می‌نوشتم فقط من و خدا می‌فهمیدیم من دارم چه کار می‌کنم. الان دیگه فقط خدا می‌دونه! 😀
ناشناس
https://t.me/bibalan_com
https://bibalan.com/?p=4652
طی چند سال گذشته و به دلیل همکاری‌ام برای انتقال (migration) زیرساخت‌های سطح پایین یکی از پیچیده‌ترین سیستم‌های نرمافزاری روی کره‌ی خاکی به نکات مهمی درباره‌ی تفاوت بین رابط (interface) و پیاده‌سازی آن (implementation) برخورد کرده‌ام. معمولن ما رابط (interface) را تجریدی (abstraction) برای ارتباط با سیستم میدانیم و پیاده‌سازی (implementation) را هم روشی میدانیم که سیستم کارش را انجام می‌دهد. برای نمونه فرمان و پدال‌های گاز و ترمز در خودرو مانند رابط عمل می‌کنند و چرخ‌ها و موتور هم مانند پیاده‌سازی هستند (ارتباط ما با خودرو از طریق فرمان و پدال‌ها است ولی خودرو به کمک موتور و چرخ‌ها کار خواسته‌شده را انجام می‌دهد). چنین مفهومی به دلایل متعددی مفید است که مهم‌ترین‌اش این است که پیچیدگی بسیاری از سیستم‌های پرکاربرد خیلی سریع به حدی می‌رسد که فهم و شناخت کامل آن برای یک فرد یا گروه دشوار می‌گردد و تجرید‌ها (abstraction) برای مدیریت این پیچیدگی بسیار مهم و حیاتی‌اند.
تعریف سطح درستِ تجرید (abstraction)، موضوع کاملن جداگانه‌ای است که در اینجا به آن نمی‌پردازیم (کتاب نفر ماه افسانه‌ای -Mythical Man-Month- را ببینید). نکته مهم این است که وقتی یک تجرید (abstraction) تعریف شد ما دوست داریم آن را غیرقابل تغییر، شفاف و تفسیرناپذیر بدانیم. به عبارت دیگر، هر رابط (interface) از دیدگاه نظری باید مرز شفافی بین استفاده‌کنندگان یک سیستم و پیاده‌سازی داخلی سیستم ترسیم کند. اما از دیدگاه عملی، با رشد تعداد استفاده‌کنندگان و استفاده از سیستم، این نظریه نقض می‌شود و استفاده‌کنندگان شروع به اعتماد و اتکا به جزییات پیاده‌سازی می‌کنند. این جزییات یا دانسته از طریق رابط (interface) به بیرون درز کرده یا خود استفاده‌کنندگان موقع استفاده از سیستم آنها را کشف کرده و فهمیده‌اند. «قانون تجریدهای دارای نشتی اسپولسکی» (Spolsky’s Law of Leaky Abstractions) توضیح می‌دهد که چگونه استفاده‌کنندگان به جزییات پیاده‌سازی اعتماد و اتکا می‌کنند.
نهایت چنین اتفاقی ما را به سوی مفهومی هدایت می‌کند که در محاوره به آن «قانون رابط‌های ضمنی یا غیرشفاف» (The Law of Implicit Interfaces) گفته می‌شود: با فرض وجود تعداد کافی از استفاده‌کنندگان، چیزی به نام پیاده‌سازی خصوصی (private implementation) وجود ندارد [پیاده‌سازی خصوصی به این معناست که استفاده‌کننده هیچ اطلاعی از نحوه و روش پیاده‌سازی داخلی سیستم ندارند].
گزیده:
وقتی داشتم این کد رو می‌نوشتم فقط من و خدا می‌فهمیدیم من دارم چه کار می‌کنم. الان دیگه فقط خدا می‌دونه! 😀
ناشناس
https://t.me/bibalan_com
https://bibalan.com/?p=4652
Telegram
سماموس: نوشته‌های یوسف مهرداد بی‌بالان
این کانال برای اطلاع‌رسانی نوشته‌های وبلاگ سماموس (bibalan.com) ایجاد شده است. مطالب پس از انتشار در وبلاگ، در این کانال نیز منتشر خواهد شد. امیدوارم که مطالب آن برای شما مفید باشد و خوشحال خواهم شد تا نظرات و بازخوردهای شما عزیزان را دریافت کنم.
👍3👏2🤔1
Forwarded from tech-afternoon (Amin Mesbahi)
📽 توضیح تکمیلی بر تحلیل ساختارمند بدهی فنی (کوادرانت فاولر)
پیش از هر چیز از دوستانی که با ری‌اکشن 🤓 برای بررسی عمیق‌تر موضوع بدهی فنی، ابراز علاقه کرده بودند متشکرم.
سعی کردم تا توی این ویدیو ۲۵ دقیقه‌ای مطلبی که چند روز پیش نوشته بودم رو عمیق‌تر توضیح بدم. امیدوارم که مفید واقع بشه.
این ویدیو در مورد بررسی ساختارمند بدهی‌های فنی با رویکرد ربع‌بندی مارتین فاولر است.
دونستن اینکه بدهی فنی ما چه خصوصیاتی داره، کمک میکنه تا جلو بازتولید بدهی‌های مشابه رو در صورت لزوم بگیریم یا راهکار بهتری برای اصلاحشون اتخاذ کنیم.
مقدمه: (0:00)
تعریف بدهی فنی: (0:37)
خصوصیات رایج بدهی‌های فنی: (3:15)
انواع بدهی فنی: (5:40)
لزوم بررسی ساختارمند بدهی فنی: (7:28)
کوادرانت (ربع‌بندی) مارتین فاولر: (12:30)
نوع اول-آگاهانه و منطقی: (13:30)
نوع دوم-ناخواسته و محتاطانه: (15:10)
نوع سوم-آگاهانه و غیرمسئولانه: (16:41)
نوع چهارم-ناآگاهانه و بی‌پروا: (17:37)
سایر طبقه‌بندی‌ها: (18:51)
جمع‌بندی: (22:35)
خیلی خوشحال می‌شم تا بهانه‌ای باشه برای هم‌فکری و گپ و گفت بیشتر 🌱💬😊
پیش از هر چیز از دوستانی که با ری‌اکشن 🤓 برای بررسی عمیق‌تر موضوع بدهی فنی، ابراز علاقه کرده بودند متشکرم.
سعی کردم تا توی این ویدیو ۲۵ دقیقه‌ای مطلبی که چند روز پیش نوشته بودم رو عمیق‌تر توضیح بدم. امیدوارم که مفید واقع بشه.
این ویدیو در مورد بررسی ساختارمند بدهی‌های فنی با رویکرد ربع‌بندی مارتین فاولر است.
دونستن اینکه بدهی فنی ما چه خصوصیاتی داره، کمک میکنه تا جلو بازتولید بدهی‌های مشابه رو در صورت لزوم بگیریم یا راهکار بهتری برای اصلاحشون اتخاذ کنیم.
مقدمه: (0:00)
تعریف بدهی فنی: (0:37)
خصوصیات رایج بدهی‌های فنی: (3:15)
انواع بدهی فنی: (5:40)
لزوم بررسی ساختارمند بدهی فنی: (7:28)
کوادرانت (ربع‌بندی) مارتین فاولر: (12:30)
نوع اول-آگاهانه و منطقی: (13:30)
نوع دوم-ناخواسته و محتاطانه: (15:10)
نوع سوم-آگاهانه و غیرمسئولانه: (16:41)
نوع چهارم-ناآگاهانه و بی‌پروا: (17:37)
سایر طبقه‌بندی‌ها: (18:51)
جمع‌بندی: (22:35)
خیلی خوشحال می‌شم تا بهانه‌ای باشه برای هم‌فکری و گپ و گفت بیشتر 🌱💬😊
YouTube
Technical Debt Quadrant
این ویدیو در مورد بررسی ساختارمند بدهی‌های فنی با رویکرد ربع‌بندی مارتین فاولر است.
دونستن اینکه بدهی فنی ما چه خصوصیاتی داره، کمک میکنه تا جلو بازتولید بدهی‌های مشابه رو در صورت لزوم بگیریم یا راهکار بهتری برای اصلاحشون اتخاذ کنیم.
مقدمه: (0:00)
تعریف…
دونستن اینکه بدهی فنی ما چه خصوصیاتی داره، کمک میکنه تا جلو بازتولید بدهی‌های مشابه رو در صورت لزوم بگیریم یا راهکار بهتری برای اصلاحشون اتخاذ کنیم.
مقدمه: (0:00)
تعریف…
👍1
Forwarded from ↻ Retro Product | رترو پروداکت
#رویداد_حضوری
⭐️ ارتباط مؤثر در فرآیند توسعه محصول
براساس بازخوردها و درخواست اعضای گروه حل مسئله رترو، و با همکاری شرکت علی‌بابا در یک رویداد حضوری در خصوص تعامل بین تیمی صحبت خواهیم کرد و تجربیات دو نفر از دوستان حاضر در تیم توسعه علی‌بابا را خواهیم شنید.
مخاطب این رویداد:
مدیران محصول، طراحان محصول و توسعه‌دهندگان نرم‌افزار
ارائه‌دهندگان:
آرزو کریم‌پور - اجایل کوچ علی‌بابا
مسعود دانش‌پور - چپتر لید علی‌بابا
علیرضا پوریوسف - بنیانگذار رترو
زمان:
پنجشنبه ۲۹ آذرماه - ساعت ۱۰ الی ۱۳
مکان:
کارخانه نوآوری آزادی، دفتر روز اول علی‌بابا
ثبت نام از طریق لینک زیر:
retro.college/event
(ظرفیت محدود است)
درآمد حاصل از فروش بلیط این رویداد به خیریه رامونا اهدا خواهد شد.
به امید دیدارتون در این رویداد
@RetroProduct
براساس بازخوردها و درخواست اعضای گروه حل مسئله رترو، و با همکاری شرکت علی‌بابا در یک رویداد حضوری در خصوص تعامل بین تیمی صحبت خواهیم کرد و تجربیات دو نفر از دوستان حاضر در تیم توسعه علی‌بابا را خواهیم شنید.
مخاطب این رویداد:
مدیران محصول، طراحان محصول و توسعه‌دهندگان نرم‌افزار
ارائه‌دهندگان:
آرزو کریم‌پور - اجایل کوچ علی‌بابا
مسعود دانش‌پور - چپتر لید علی‌بابا
علیرضا پوریوسف - بنیانگذار رترو
زمان:
پنجشنبه ۲۹ آذرماه - ساعت ۱۰ الی ۱۳
مکان:
کارخانه نوآوری آزادی، دفتر روز اول علی‌بابا
ثبت نام از طریق لینک زیر:
retro.college/event
(ظرفیت محدود است)
درآمد حاصل از فروش بلیط این رویداد به خیریه رامونا اهدا خواهد شد.
(تفاوت بلیط اول و دوم فقط در عدد اهدایی شما برای خیریه خواهد بود)
در صورتی که سوالی داشتید میتونید از اکانت ادمین بپرسید:
@RetroAdmin
به امید دیدارتون در این رویداد
@RetroProduct
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍2❤1🆒1
Forwarded from tech-afternoon (Amin Mesbahi)
🌟 ساده نگه داشتن سیستم‌ها، ۶ درس از Werner Vogels
حرف‌های زیادی میشه درباره AWS زد، اما واقعیت اینه که این غول کلود، سیستم‌ها و سرویس‌هاش رو طی دو دهه با موفقیت scale کرده و همچنان کاربری راحتش رو حفظ کرده.
ورنر فوگلس، CTO آمازون، تو کنفرانس AWS re:Invent درس‌های جذابی از تجربه‌اش تو نگهداری سیستم‌های پیچیده مطرح کرد.
💫 نکته کلیدی؟ پیچیدگی همیشه توی طراحی سیستم‌ها کمین میکنه، پس مهندس باید هوشیار باشه.
💫 هدف این نیست که پیچیدگی رو کلا حذف کنیم، بلکه باید اون رو مدیریت کنیم. لری تسلر میگه: "پیچیدگی رو نمیشه حذف کرد، فقط میشه جابجاش کرد".
یه مثال جالب: طراحی دوچرخه!
یک چرخه: خیلی انعطاف‌پذیره، اما سوار شدنش سخته
سه چرخه: راحته، ولی جابجا کردنش سخته
دوچرخه: تعادل ایده‌آل بین راحتی و انعطاف‌پذیری
۶ توصیه Vogels برای مدیریت پیچیدگی:
۱. سیستم‌های قابل تکامل بسازید
نرم‌افزارهایی که پیش نمیرن، میمیرن
هر بار که مقیاس سیستم عوض میشه، باید معماری رو بازنگری کنید
۲. پیچیدگی رو خرد کنید
تغییرات کوچک رو نادیده نگیرید
هر سرویس باید اونقدر کوچک باشه که تو ذهن یه مهندس جا بشه
۳. معماری رو با نیازهای کسب‌وکار هماهنگ کنید
اجزای هوشمند با رابط‌های ریزدانه بسازید
با واحدهای کسب‌وکار همکاری کنید
۴. کار رو به سلول‌ها تقسیم کنید
معماری سلولی پیچیدگی رو مدیریت میکنه
مشکلات رو محدود میکنه بدون تاثیر روی کل سیستم
۵. سیستم‌های پیش‌بینی‌پذیر طراحی کنید
عدم قطعیت رو کاهش بدید
از معماری‌های با پالس ثابت استفاده کنید
۶. همه چی رو اتوماتیک کنید
اتوماسیون استاندارد باشه
فقط جاهایی که نیاز به قضاوت انسانی هست، دخالت انسان لازمه
💫 خلاصه کلام: "سادگی نیاز به انضباط داره" - Werner Vogels
در موردش صحبت کنیم؟ نظر شما چیه؟
حرف‌های زیادی میشه درباره AWS زد، اما واقعیت اینه که این غول کلود، سیستم‌ها و سرویس‌هاش رو طی دو دهه با موفقیت scale کرده و همچنان کاربری راحتش رو حفظ کرده.
ورنر فوگلس، CTO آمازون، تو کنفرانس AWS re:Invent درس‌های جذابی از تجربه‌اش تو نگهداری سیستم‌های پیچیده مطرح کرد.
💫 نکته کلیدی؟ پیچیدگی همیشه توی طراحی سیستم‌ها کمین میکنه، پس مهندس باید هوشیار باشه.
💫 هدف این نیست که پیچیدگی رو کلا حذف کنیم، بلکه باید اون رو مدیریت کنیم. لری تسلر میگه: "پیچیدگی رو نمیشه حذف کرد، فقط میشه جابجاش کرد".
یه مثال جالب: طراحی دوچرخه!
یک چرخه: خیلی انعطاف‌پذیره، اما سوار شدنش سخته
سه چرخه: راحته، ولی جابجا کردنش سخته
دوچرخه: تعادل ایده‌آل بین راحتی و انعطاف‌پذیری
۶ توصیه Vogels برای مدیریت پیچیدگی:
۱. سیستم‌های قابل تکامل بسازید
نرم‌افزارهایی که پیش نمیرن، میمیرن
هر بار که مقیاس سیستم عوض میشه، باید معماری رو بازنگری کنید
۲. پیچیدگی رو خرد کنید
تغییرات کوچک رو نادیده نگیرید
هر سرویس باید اونقدر کوچک باشه که تو ذهن یه مهندس جا بشه
۳. معماری رو با نیازهای کسب‌وکار هماهنگ کنید
اجزای هوشمند با رابط‌های ریزدانه بسازید
با واحدهای کسب‌وکار همکاری کنید
۴. کار رو به سلول‌ها تقسیم کنید
معماری سلولی پیچیدگی رو مدیریت میکنه
مشکلات رو محدود میکنه بدون تاثیر روی کل سیستم
۵. سیستم‌های پیش‌بینی‌پذیر طراحی کنید
عدم قطعیت رو کاهش بدید
از معماری‌های با پالس ثابت استفاده کنید
۶. همه چی رو اتوماتیک کنید
اتوماسیون استاندارد باشه
فقط جاهایی که نیاز به قضاوت انسانی هست، دخالت انسان لازمه
💫 خلاصه کلام: "سادگی نیاز به انضباط داره" - Werner Vogels
در موردش صحبت کنیم؟ نظر شما چیه؟
❤6
7 هزینه مرگبار در توسعه نرم‌افزار 🚀
1️⃣ ⏳ کارهای نیمه‌تمام کدایی که نصفه مونده یا فیچرایی که تست نشدن، فقط وقت تیم رو می‌گیره! کوچیک و کامل تحویل بده.
2️⃣ 📦 فیچرای اضافه فیچری که کسی نمی‌خواد نساز! فقط چیزایی که کاربرا نیاز دارن رو پیاده کن. وقت و هزینه هدر نده.
3️⃣ 🧠 دوباره‌کاری و یادگیری مجدد هر بار کد رو باز می‌کنی یادت میره چی بوده؟ کامنت بذار، مستند کن، آینده خودت رو نجات بده!
4️⃣ 🤝 دست به دست کردن کارها از توسعه به تست، از فرانت به بک! هر چی دست به دست بشه، احتمال باگ و اشتباه بیشتر میشه.
5️⃣ 🕒 معطل موندن منتظر تایید، کد ریویو یا دسترسی به ابزار؟ تایم مرده زیاده! پروسه‌ها رو روان‌تر کن.
6️⃣ 🔄 تغییر بین چند کار چند تا تسک همزمان تمرکز می‌پره، بهره‌وری صفر میشه! اول یکی رو ببند، بعد برو سراغ بعدی.
7️⃣ 🐛 باگ و خطاهای پنهان خطاهایی که ارور نمی‌دن، اعصاب می‌سوزونن! لاگ بگیر، تست بنویس و سریع فیدبک بگیر تا غافلگیر نشی.
🧐 کدوم یکی از اینا رو تو تیم‌تون بیشتر دیدی؟ بیا بحث کنیم، شاید راه حلی پیدا شد! 👇👇
1️⃣ ⏳ کارهای نیمه‌تمام کدایی که نصفه مونده یا فیچرایی که تست نشدن، فقط وقت تیم رو می‌گیره! کوچیک و کامل تحویل بده.
2️⃣ 📦 فیچرای اضافه فیچری که کسی نمی‌خواد نساز! فقط چیزایی که کاربرا نیاز دارن رو پیاده کن. وقت و هزینه هدر نده.
3️⃣ 🧠 دوباره‌کاری و یادگیری مجدد هر بار کد رو باز می‌کنی یادت میره چی بوده؟ کامنت بذار، مستند کن، آینده خودت رو نجات بده!
4️⃣ 🤝 دست به دست کردن کارها از توسعه به تست، از فرانت به بک! هر چی دست به دست بشه، احتمال باگ و اشتباه بیشتر میشه.
5️⃣ 🕒 معطل موندن منتظر تایید، کد ریویو یا دسترسی به ابزار؟ تایم مرده زیاده! پروسه‌ها رو روان‌تر کن.
6️⃣ 🔄 تغییر بین چند کار چند تا تسک همزمان تمرکز می‌پره، بهره‌وری صفر میشه! اول یکی رو ببند، بعد برو سراغ بعدی.
7️⃣ 🐛 باگ و خطاهای پنهان خطاهایی که ارور نمی‌دن، اعصاب می‌سوزونن! لاگ بگیر، تست بنویس و سریع فیدبک بگیر تا غافلگیر نشی.
🧐 کدوم یکی از اینا رو تو تیم‌تون بیشتر دیدی؟ بیا بحث کنیم، شاید راه حلی پیدا شد! 👇👇
👍19❤1🤔1
خب سال 2024 من خیلی روی Github فعال نبودم و بیشتر کارم روی Source-Control شخصیم بود.
💎 ولی امسال برنامم اینه که حسابی روی گیت هاب فعال بشم.
🔗 اگر شما هم میخواید وضعیت گیت هابتون و فعالبتتون توی سال گذشته رو ببینید از این آدرس استفاده کنید :
https://git-wrapped.com/
💎 ولی امسال برنامم اینه که حسابی روی گیت هاب فعال بشم.
🔗 اگر شما هم میخواید وضعیت گیت هابتون و فعالبتتون توی سال گذشته رو ببینید از این آدرس استفاده کنید :
https://git-wrapped.com/
👍5🔥1
Forwarded from tech-afternoon (Amin Mesbahi)
🚀 💸 یک خبر خوب! امروز گیت‌هاب از سرویس رایگان کوپایلوت رونمایی کرد و بلافاصله هم تیم ویژوال‌استدیو نسخه رایگان رو برای ویژوال‌استدیو ارائه کرد.
من دو ساله مشترک کاپایلوت هستم و حقیقتا سرویس خوبیه. حتی از IntelliCode و JetBrains AI و Tabnine و Cody و Tabby هم که من تست کردم بهتر بوده (در تست‌ها و نیازهای شخصی من، که قطعا جهان‌شمول نیست)
و AI چند ساله که کم‌کم بخشی از هزینه‌های سبد خانواده شده که باید بهش جدی‌تر فکر کرد. از بس که متعدد شدن!
خبر گیت‌هاب
خبر ویژوال‌استدیو
خبر VS Code
من دو ساله مشترک کاپایلوت هستم و حقیقتا سرویس خوبیه. حتی از IntelliCode و JetBrains AI و Tabnine و Cody و Tabby هم که من تست کردم بهتر بوده (در تست‌ها و نیازهای شخصی من، که قطعا جهان‌شمول نیست)
و AI چند ساله که کم‌کم بخشی از هزینه‌های سبد خانواده شده که باید بهش جدی‌تر فکر کرد. از بس که متعدد شدن!
خبر گیت‌هاب
خبر ویژوال‌استدیو
خبر VS Code
❤9👍6🔥3
📢 معرفی Semantic Kernel مایکروسافت: گامی به سوی هوش مصنوعی قدرتمند در توسعه نرم‌افزار 🚀
🔍 ابزار Semantic Kernel چیست؟
ابزار Semantic Kernel یک کتابخانه متن‌باز از مایکروسافت است که به توسعه‌دهندگان کمک می‌کند هوش مصنوعی (AI) و مدل‌های زبان بزرگ (LLM) مانند ChatGPT و GPT-4 را به برنامه‌های خود اضافه کنند. این ابزار، قدرت هوش مصنوعی را با منطق‌های سنتی کدنویسی ترکیب می‌کند.
💡 قابلیت‌های کلیدی Semantic Kernel:
✨قابلیت Skills (مهارت‌ها): تعریف و اجرای مهارت‌های مبتنی بر هوش مصنوعی برای انجام کارهای پیچیده.
🔗 اتصال به مدل‌های LLM: اتصال آسان به مدل‌های OpenAI و Azure OpenAI.
🧠داشتن Memory (حافظه): قابلیت ذخیره و بازیابی اطلاعات برای شخصی‌سازی تجربه کاربری.
🗂️امکان Planner (برنامه‌ریز): ایجاد و اجرای برنامه‌های پویا برای مدیریت اهداف و وظایف.
📡 قابلیت Connectors (اتصال‌دهنده‌ها): امکان ادغام با سرویس‌های شخص ثالث و APIهای دیگر.
💥 چرا Semantic Kernel مهم است؟
اگر بخواهید یک چت‌بات پیشرفته، یک سیستم پاسخ‌گویی خودکار، یا یک برنامه مدیریت هوشمند بسازید، Semantic Kernel این امکان را برای شما فراهم می‌کند تا هوش مصنوعی را به راحتی در کدهای C# و Python خود ادغام کنید.
🌐 مناسب برای توسعه‌دهندگان C# و Python
ابزار Semantic Kernel به شما امکان می‌دهد مهارت‌های هوش مصنوعی را در پروژه‌های نرمافزاری خود بگنجانید. اگر به دنبال ساخت سیستم‌های هوشمند با AI هستید، این ابزار دقیقاً همان چیزی است که نیاز دارید!
به زودی یک ویدیو برای پیاده سازی Semantic Kernel و اتصالش به AvvalAI پست می کنم که ببینید چطوری میشه پروژه هایی بر بستر AI داشته باشید.
📢 نظر شما درباره Semantic Kernel چیه؟ آیا به این تکنولوژی علاقه‌مندید؟ 👇
🔍 ابزار Semantic Kernel چیست؟
ابزار Semantic Kernel یک کتابخانه متن‌باز از مایکروسافت است که به توسعه‌دهندگان کمک می‌کند هوش مصنوعی (AI) و مدل‌های زبان بزرگ (LLM) مانند ChatGPT و GPT-4 را به برنامه‌های خود اضافه کنند. این ابزار، قدرت هوش مصنوعی را با منطق‌های سنتی کدنویسی ترکیب می‌کند.
💡 قابلیت‌های کلیدی Semantic Kernel:
✨قابلیت Skills (مهارت‌ها): تعریف و اجرای مهارت‌های مبتنی بر هوش مصنوعی برای انجام کارهای پیچیده.
🔗 اتصال به مدل‌های LLM: اتصال آسان به مدل‌های OpenAI و Azure OpenAI.
🧠داشتن Memory (حافظه): قابلیت ذخیره و بازیابی اطلاعات برای شخصی‌سازی تجربه کاربری.
🗂️امکان Planner (برنامه‌ریز): ایجاد و اجرای برنامه‌های پویا برای مدیریت اهداف و وظایف.
📡 قابلیت Connectors (اتصال‌دهنده‌ها): امکان ادغام با سرویس‌های شخص ثالث و APIهای دیگر.
💥 چرا Semantic Kernel مهم است؟
اگر بخواهید یک چت‌بات پیشرفته، یک سیستم پاسخ‌گویی خودکار، یا یک برنامه مدیریت هوشمند بسازید، Semantic Kernel این امکان را برای شما فراهم می‌کند تا هوش مصنوعی را به راحتی در کدهای C# و Python خود ادغام کنید.
🌐 مناسب برای توسعه‌دهندگان C# و Python
ابزار Semantic Kernel به شما امکان می‌دهد مهارت‌های هوش مصنوعی را در پروژه‌های نرمافزاری خود بگنجانید. اگر به دنبال ساخت سیستم‌های هوشمند با AI هستید، این ابزار دقیقاً همان چیزی است که نیاز دارید!
به زودی یک ویدیو برای پیاده سازی Semantic Kernel و اتصالش به AvvalAI پست می کنم که ببینید چطوری میشه پروژه هایی بر بستر AI داشته باشید.
📢 نظر شما درباره Semantic Kernel چیه؟ آیا به این تکنولوژی علاقه‌مندید؟ 👇
👍11❤1
Forwarded from tech-afternoon (Amin Mesbahi)
مفهوم Resiliency یا تاب‌آوری، به توانایی یک سیستم برای بازیابی شرایط پایدار در صورت بروز خطا گفته میشه. حالا این بازیابی می‌تونی تلاش برای بازیابی باشه، یا انتخاب راه جایگزین. مثل اینکه شما ۲ بار تلاش می‌کنی از API آب‌وهوا مقدار دمای فعلی یک منطقه رو بگیری، هر بار با فاصله زمانی ۵ ثانیه API رو صدا می‌زنی ولی بعد از اینکه پاسخ موفق نمی‌گیری (تا اینجا به این می‌گن استراتژی retry) بعد تصمیم می‌گیری از cache آخرین مقداری که کمتر از ۵ ساعت گذشته وجود داشته رو استفاده کنی که فعلا کار راه بیوفته (استراتژی fallback) یا ... به هر کدوم از این رفتارها برای تداوم کار و مقابله با موانع، می‌گن resiliency strategy.
کتابخونه Polly محبوب‌ترین در بین دات‌نتی‌هاست. و تو دل Aspire هم ازش استفاده شده، برای درک بهتر ویدیوی Aspire که به زودی پابلیش میشه، خوبه یه مرور روی انواع استراتژی‌ها کنیم...
—————————
دو گروه اصلی داریم:
وقتی به کار می‌رن که یک خطا یا مشکلی رخ داده و سیستم باید به شکلی واکنش نشون بده.
فرضیه: خطاها موقتی هستن و ممکنه با کمی تأخیر و تلاش مجدد برطرف بشن.
در این استراتژی، سیستم تلاش میکنه که یک عملیات ناموفق رو بعد از یک بازه‌ی زمانی مشخص دوباره امتحان کنه. این بازه زمانی می‌تونه ثابت یا متغیر باشه (مثل Exponential Backoff). مثلاً اگر سرور موقتی قطع شده باشه، با چند بار Retry ممکنه مشکل حل بشه. در Polly، این با “Retry Policy” قابل پیاده‌سازی است. و تعداد دفعات و بازه زمانی بین هر تلاش به تصمیم ما وابسته است.
فرضیه: وقتی سیستم به شدت دچار مشکل میشه، بهتره سریعاً فرآیندها متوقف بشن به جای اینکه کاربران منتظر بمونن.
چطور کمک میکنه؟ مدار رو قطع میکنه (اجرای درخواست‌ها رو متوقف میکنه) در زمانی که خطاها از حدی مشخص بیشتر می‌شن (مثل وقتی می‌فرسته به صف ولی هِی روی هم انباشت میشه و از اون طرف پردازش نمی‌شن)
شبیه به فیوز برق که اگر بیش از حد فشار وارد بشه، مدار رو قطع میکنه. این استراتژی به سیستم اجازه میده برای مدتی مشخص درخواست‌ها رو به مقصد ارسال نکنه تا از خرابی‌های بیشتر جلوگیری بشه. مثلاً در Polly میتونید مدت‌زمانی که Circuit باز می‌مونه و شرایط بازگشت به حالت نرمال رو تنظیم کنیم.
فرضیه: خطا تداوم خواهد داشت؛ پس برای پلن B برنامه‌ریزی می‌کنیم.
چطوری کمک میکنه؟ یک مقدار یا راه حل جایگزین در صورت بروز یا تداوم خطا ارائه میده.
وقتی یک عملیات شکست می‌خوره، به جای نمایش خطا به کاربر، یک نتیجه جایگزین برمی‌گرده. مثلاً به جای اینکه پیام “سرور API در دسترس نیست” نمایش داده بشه، میتونید یک مقدار ذخیره شده از کش رو ارائه بدید.
فرضیه: گاهی اوقات برخی مسیرها شاید کند یا حتی ناموفق باشن؛ پس بهتره چندین راه برای رسیدن به هدف در نظر بگیریم، هر کدوم زودتر جواب داد، همون.
چطوری کمک میکنه؟ برای یک کار، چند راه رو تلاش میکنه به طور موازی پی بگیره و منتظر اولین پاسخ موفق می‌مونه.
در این استراتژی، همزمان چند درخواست به چند مقصد مختلف ارسال میشه و اولین پاسخ موفق به عنوان نتیجه پذیرفته میشه. این کار برای کاهش زمان انتظار و بهبود اطمینان‌پذیری استفاده میشه.
این استراتژی‌ها برای پیشگیری از بروز مشکلات در سیستم طراحی شده‌اند.
فرضیه: بعد از مدت زمانی مشخص، موفقیت بعیده.
چطوری کمک میکنه؟ تضمین میکنه که درخواست‌ها بیشتر از زمان مشخص منتظر نمی‌مونن.
در این استراتژی، زمان محدودی برای انجام یک عملیات در نظر گرفته میشه. اگر عملیات در این زمان به نتیجه نرسید، سیستم اون رو قطع میکنه. این کار مانع از این میشه که یک درخواست معلق منابع سیستم رو اشغال کنه.
فرضیه: محدود کردن تعداد درخواست‌هایی که سیستم در یک بازه زمانی مشخص می‌پذیره (راهی برای کنترل بار ورودی).
چطوری کمک میکنه؟ اجرای درخواست‌ها رو محدود میکنه تا از حد مشخصی فراتر نره.
برای جلوگیری از بار زیاد روی سیستم، این استراتژی تعداد درخواست‌ها در یک بازه زمانی مشخص رو محدود میکنه. مثلاً اگر کاربران زیادی همزمان به سیستم درخواست بفرستن، Rate Limiter می‌تونه از خرابی جلوگیری کنه.
—————————
ما می‌تونیم از یک یا ترکیبی از چند استراتژی برای افزایش تاب‌آوری سیستم‌هامون استفاده کنیم.
🔗 رفرنس جهت مطالعه عمیق‌تر
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍1
#موقت
آقا نگید یه وقت چرا همش از کانال استاد فوروارد می کنی.
استاد مصباحی ماشالله گنجینه ای تمام نشدنی هستند، ۲۰ برابر من هم تعهد به انجام کار و انتقال دانش دارن.
حیفه نتیجه تحقیقات و دانششون رو منتشر نکرد.
آقا نگید یه وقت چرا همش از کانال استاد فوروارد می کنی.
استاد مصباحی ماشالله گنجینه ای تمام نشدنی هستند، ۲۰ برابر من هم تعهد به انجام کار و انتقال دانش دارن.
حیفه نتیجه تحقیقات و دانششون رو منتشر نکرد.
❤16
Forwarded from TechTube 𝕏 تک توب
This media is not supported in your browser
VIEW IN TELEGRAM
گوگل ابزاری به نام Whisk رو عرضه کرده که امکان ترکیب عکسهای مختلف با هوش مصنوعی رو میده.
در این ابزار یک تصویر به عنوان سوژه، یک تصویر برای الهام گیری از اون برای پس زمینه و یک تصویر برای مشخص کردن استایل عکس، اپلود میکنید یا هر کدوم از اونهارو با تایپ پرامپت مدنظرتون وارد میکنید و در نهایت هوش مصنوعی ساخت عکس جدید Imagen 3 اونهارو با هم ترکیب میکنه و عکسی مدنظرتونه رو تحویل میده.
این ابزار از اینجا به صورت رایگان قابل استفاده هست ولی برای دسترسی به اون IP امریکا نیازه.
🔎 blog.google
📍 @TechTube
در این ابزار یک تصویر به عنوان سوژه، یک تصویر برای الهام گیری از اون برای پس زمینه و یک تصویر برای مشخص کردن استایل عکس، اپلود میکنید یا هر کدوم از اونهارو با تایپ پرامپت مدنظرتون وارد میکنید و در نهایت هوش مصنوعی ساخت عکس جدید Imagen 3 اونهارو با هم ترکیب میکنه و عکسی مدنظرتونه رو تحویل میده.
این ابزار از اینجا به صورت رایگان قابل استفاده هست ولی برای دسترسی به اون IP امریکا نیازه.
🔎 blog.google
📍 @TechTube
👍3
جمله روز
- Stephen Hawking
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge.
- Stephen Hawking
👍17👏3🤔1
💎 یه توصیه به خودم می کنم :
آقا داکیومنت ابزار رو بخون بعد سرچ کن، توی داکیومنت خوندن هم اونجا هایی که بولد شده یا توی باکس رنگی گذاشتن یه دلیلی داشته و مهم بوده !
پ.ن: بعد از 4 ساعت ور رفتن با Masstransit و سرچ و ChatGPT آخرش مشکل توی داکیومنت Masstransit همون صفحه اول بود ! 😮💨
آقا داکیومنت ابزار رو بخون بعد سرچ کن، توی داکیومنت خوندن هم اونجا هایی که بولد شده یا توی باکس رنگی گذاشتن یه دلیلی داشته و مهم بوده !
پ.ن: بعد از 4 ساعت ور رفتن با Masstransit و سرچ و ChatGPT آخرش مشکل توی داکیومنت Masstransit همون صفحه اول بود ! 😮💨
👍30😁7
همونطور که احتمالا در جریان هستید، تیم .Net به دلیل اینکه
این یعنی اگر شما پروژه جدید با .Net 9 بسازید و پروژه رو اجرا کنید، به جای صفحه
و این یعنی اگر صفحه
💎 خب،از اونجایی که برای ارتباط بهتر استفاده کنندهای API های ما یا تست خودمون، اگر یک UI مثل Swagger داشته باشیم خیلی راحت تریم باید به فکر جایگزین باشیم.
شما هنوز می تونید به صورت دستی Swashbuckle رو اضافه کنید و کانفیگش کنید، ولی از اونجایی که بعضی وقت ها : عدو شود سبب خیر من یکم گشتم و گشتم تا یک جایگزین خوب پیدا کنم.
این شما و این
این جناب Scalar یک پروژه اوپن سورس هست که خیلی کلاینت های مختلفی از جمله .Net داره که به شما کمک میکنه یک کلاینت تر و تمیز و با قابلیت هایی به مراتب بهتر از Swashbuckle برای کار با API های خودتون داشته باشید.
پیاده سازی و نصب راحتی داره، فقط کافیه که اول به پروژه اضافش کنید :
و بعد به دستور زیر پیکر بندیش کنید :
هممون هم حواسمون هست که ابزار ها فقط برای محیط های Development و Staging هستند و نباید برن روی Production !
شما از چه ابزاری روی .Net 9 دارید استفاده می کنید ؟ چالش چی تو دست و بالتون دارید ؟ 😂
Swashbuckle به درستی آپدیت نمی شد و مشکلاتش رفع نمی شد، از .Net 9 این لایبرری رو حذف کردند.این یعنی اگر شما پروژه جدید با .Net 9 بسازید و پروژه رو اجرا کنید، به جای صفحه
Swagger با 404 رو برو می شید. در عوض تیم .Net، پیاده سازی OpenAPI رو اضافه کردن. برای همینه که توی program.cs شما فقط کد های زیر رو می بینید :builder.Services.AddOpenApi()
app.MapOpenApi();
و این یعنی اگر صفحه
openapi/v1.json رو باز کنید با یک فایل json مواجه میشید که وظیفه تولید مستندات OpenAPI رو داره.💎 خب،از اونجایی که برای ارتباط بهتر استفاده کنندهای API های ما یا تست خودمون، اگر یک UI مثل Swagger داشته باشیم خیلی راحت تریم باید به فکر جایگزین باشیم.
شما هنوز می تونید به صورت دستی Swashbuckle رو اضافه کنید و کانفیگش کنید، ولی از اونجایی که بعضی وقت ها : عدو شود سبب خیر من یکم گشتم و گشتم تا یک جایگزین خوب پیدا کنم.
این شما و این
Scalar.این جناب Scalar یک پروژه اوپن سورس هست که خیلی کلاینت های مختلفی از جمله .Net داره که به شما کمک میکنه یک کلاینت تر و تمیز و با قابلیت هایی به مراتب بهتر از Swashbuckle برای کار با API های خودتون داشته باشید.
پیاده سازی و نصب راحتی داره، فقط کافیه که اول به پروژه اضافش کنید :
dotnet add package Scalar.AspNetCore
و بعد به دستور زیر پیکر بندیش کنید :
app.MapScalarApiReference();
هممون هم حواسمون هست که ابزار ها فقط برای محیط های Development و Staging هستند و نباید برن روی Production !
شما از چه ابزاری روی .Net 9 دارید استفاده می کنید ؟ چالش چی تو دست و بالتون دارید ؟ 😂
👍21👏1
عزیزان زحمت کشیدن حق مسلممون رو بهمون برگردوندند.
گویا واتس آپ به درد نخور و گوگل پلی رفع فیلتر شد !
گویا واتس آپ به درد نخور و گوگل پلی رفع فیلتر شد !
🤣12👍9
#فان 😆
پ.ن ۱ : کدی که سخت نوشته میشه، معمولا غلطه دیزاین شده که انقدر سخت نوشته شده.
پ.ن ۲: از نظر من کد خوب خودشو توصیف می کنه و کامنت معنی نمیده. کامنت فقط برای توضیح خود متد اونم روی اینترفیسش که امپلیمنتیشن رو نمیبینیم به درد می خوره.
نظر شما چیه؟
پ.ن ۱ : کدی که سخت نوشته میشه، معمولا غلطه دیزاین شده که انقدر سخت نوشته شده.
پ.ن ۲: از نظر من کد خوب خودشو توصیف می کنه و کامنت معنی نمیده. کامنت فقط برای توضیح خود متد اونم روی اینترفیسش که امپلیمنتیشن رو نمیبینیم به درد می خوره.
نظر شما چیه؟
👍13❤4🔥1🤡1
Forwarded from tech-afternoon (Amin Mesbahi)
🧠 مروری بر Semantic Kernel، نرم‌افزار، ولی باهوش!
شاید شوخی دور از واقعیتی نباشه که طی این چند سال، اینقدر که همه روی AI تمرکز کردن یا باهاش شوآف کردن، اگر روی پیدا کردن قاتل بروسلی وقت گذاشته بودن حتمن اون نامرد رو دستگیر کرده بودن!
مایکروسافت هم که به لطف سرمایه‌گذاری‌های هوشمندانه‌ای که روی استارتاپ‌ها و شرکت‌های مستعد داشته، اوضاع خیلی خوبی داره. یادمون نره همونطور که برنامه‌نویسی وب یا معماری سرویس‌گرا، ۲۵ سال پیش چیزهای مدرنی بودن ولی الان بدیهی و پیش‌پا افتاده به شمار میان؛ استفاده از AI توی نرم‌افزارها هم تا چند وقت دیگه (خیلی خیلی کمتر از ۲۵ سال، حتی کمتر از ۵ سال دیگه) یه موضوع بدیهی خواهد بود.
🎅 دو تا خاطره توی کامنت این مطلب می‌گذارم (خاطره است و اگر نخونید چیزی از مطلب رو از دست ندادید)
البته منظورم چپوندن زورکی و شوآف نیست، بلکه چیزی برای تسهیل نیازهای کاربر نهایی و ارتقاء عملکرد خود سیستمه.
کتابخونه Semantic Kernel که فقط هم برای دات‌نتی‌ها نیست و پایتون و جاوا رو هم پشتیبانی میکنه؛ یک کتابخونه‌ی متن‌بازه که به عنوان میان‌افزار (middleware) عمل می‌کند.
❓ یعنی چی؟ یعنی این کتابخونه به توسعه‌دهنده کمک میکنه تا به سادگی مدل‌های هوش مصنوعی مختلف رو با کدهای موجودش ترکیب کنه و عامل‌های هوشمند (AI agents) بسازه، (بدون داشتن درک عمیق از دل و روده‌ی AI یا LLM)
❓ یکم بیشتر؟ چشم. مثلا شما می‌خواهید از مدلی که یه بابایی یا یه شرکتی، رایگان یا پولی، روی کامپیوتر خودتون یا روی کلاد، وجود داره و مثلا بهش یه متن می‌دید و می‌گید با صدای فلان خواننده بخونه؛ یا یه متن می‌دید می‌گید یه عکس بر اساسش بسازه؛ یا سوال و جواب عادی؛ یا سوال و جوابی که مبنای پاسخش دیتای توی دیتابیس شماست؛
مثلا شما یه نرم‌افزار سنتی فروشگاه آنلاین لباس داری؛ کاربر میگه برام یه ست لباس مهمونی برای فصل پاییز و سقف قیمت فلان، برای یک خانم ۳۰ ساله با سایز M پیشنهاد کن، این یه متنه، ولی Semantic Kernel این امکان رو میده به راحتی از دل دیتای ساختار یافته دیتابیس، فرض کنید جدولی که نام کالا، قیمت، رنگ و سایز رو داره، کوئری مورد نیاز رو بسازه. چجوری؟ با دیتایی که توی مدل زبانی داره می‌فهمه رنگ‌های مناسب با پاییز، یا نوع لباس‌های مورد نیاز برای یک مهمانی (شلوار، پیراهن، پالتو، کفش، شال‌گردن برای پاییز و یک خانم نیازه) اینا رو از دل دیتابیس می‌کشه بیرون و متن هم از نتیج خروجی که احتمالا یه لیست از آبجکت کالا است بسازه که: فلانی‌جون اگر اینو اونو اون‌یکی رو ست کنی برای پاییز خوبه و به بودجه‌ات هم می‌خوره!
🧞♂️ این یه روزی جادو بود، یه روز رویا بود، یه روز محال بود؛ الان با وجود امکانات ساختاری وکتورها و کتابخونه‌ها به راحتی شدنیه، حتی با تغییرات کم در کدهای فعلی!
این Semantic Kernel در حقیقت یه پُله بین دنیای برنامه‌نویسی سنتی و مدل‌های زبانی بزرگ (LLM).
فعلا هم با زبون‌های C#، Python و Java قابل استفاده است. یه لایه‌ی میانی که درخواست‌های مدل‌های AI رو به توابع تعریف‌شده توی کد ترجمه میکنه و پاسخ‌ها را مدیریت میکنه (تبدیل متن به یه کلاس، و ساخت متن با استفاده از دیتای ساختاریافته).
مدل‌های هوش مصنوعی مثل GPT و DALL-E و… تحول بزرگی توی نحوه تعامل ما با نرم‌افزار ایجاد کردن. اما استفاده از این مدل‌ها توی محیط‌های واقعی چالش‌هایی هم داره:
🔤 مدیریت درخواست‌ها: چجوری درخواست‌های پیچیده کاربر رو به توابع کدنویسی ترجمه کنیم؟ (مثلا ورودی‌های متد GetProductsByDescription)
🔤 اتصال به سیستم‌های موجود: چجوری هوش مصنوعی با APIها، دیتابیس‌ها، یا فرآیندهای کسب‌وکاری تعامل داشته باشه؟
🔤 امنیت و مقیاس‌پذیری: چجوری میشه این قابلیت‌ها رو به‌صورت ایمن (جلوگیری از نشت اطلاعات یا دسترسی به داده‌هایی که نباید بهش دسترسی داشته باشع) و توی مقیاس بزرگ ارائه کرد؟
و Semantic Kernel برای پاسخ به این چالش‌ها طراحی شد؛ و هدفش ساده‌سازی یکپارچه‌سازی هوش مصنوعی در پروژه‌های واقعیه.
👀 چی کار میشه باهاش کرد حالا؟
- ایجاد ربات‌ها و عامل‌های هوشمند: مثل چت‌بات‌هایی که به‌صورت پویا تصمیم می‌گیرن یا فرآیندها رو خودکار می‌کنن.
- یکپارچه‌سازی آسون با کد موجود: با استفاده از قابلیت Function Calling، میشه مدل‌های AI رو به کدهای موجود متصل کرد.
- اتوماسیون فرآیندهای کسب‌وکار: مثل پردازش خودکار درخواست‌های مشتری‌ها یا مدیریت منابع سازمانی.
- مدیریت آسون هوش مصنوعی: فراهم کردن قابلیت مشاهده و نظارت بر عملکرد مدل‌های مختلف.
- اتصال به مدل‌های مختلف AI (مثل OpenAI، یا مدل‌هایی که روی ماشین خودتون دارید)
- پشتیبانی از Vector Storeها
✨ اگر دوست دارید این موضوع ادامه بدم:
ری‌اکشن 🤓
شاید شوخی دور از واقعیتی نباشه که طی این چند سال، اینقدر که همه روی AI تمرکز کردن یا باهاش شوآف کردن، اگر روی پیدا کردن قاتل بروسلی وقت گذاشته بودن حتمن اون نامرد رو دستگیر کرده بودن!
مایکروسافت هم که به لطف سرمایه‌گذاری‌های هوشمندانه‌ای که روی استارتاپ‌ها و شرکت‌های مستعد داشته، اوضاع خیلی خوبی داره. یادمون نره همونطور که برنامه‌نویسی وب یا معماری سرویس‌گرا، ۲۵ سال پیش چیزهای مدرنی بودن ولی الان بدیهی و پیش‌پا افتاده به شمار میان؛ استفاده از AI توی نرم‌افزارها هم تا چند وقت دیگه (خیلی خیلی کمتر از ۲۵ سال، حتی کمتر از ۵ سال دیگه) یه موضوع بدیهی خواهد بود.
البته منظورم چپوندن زورکی و شوآف نیست، بلکه چیزی برای تسهیل نیازهای کاربر نهایی و ارتقاء عملکرد خود سیستمه.
کتابخونه Semantic Kernel که فقط هم برای دات‌نتی‌ها نیست و پایتون و جاوا رو هم پشتیبانی میکنه؛ یک کتابخونه‌ی متن‌بازه که به عنوان میان‌افزار (middleware) عمل می‌کند.
مثلا شما یه نرم‌افزار سنتی فروشگاه آنلاین لباس داری؛ کاربر میگه برام یه ست لباس مهمونی برای فصل پاییز و سقف قیمت فلان، برای یک خانم ۳۰ ساله با سایز M پیشنهاد کن، این یه متنه، ولی Semantic Kernel این امکان رو میده به راحتی از دل دیتای ساختار یافته دیتابیس، فرض کنید جدولی که نام کالا، قیمت، رنگ و سایز رو داره، کوئری مورد نیاز رو بسازه. چجوری؟ با دیتایی که توی مدل زبانی داره می‌فهمه رنگ‌های مناسب با پاییز، یا نوع لباس‌های مورد نیاز برای یک مهمانی (شلوار، پیراهن، پالتو، کفش، شال‌گردن برای پاییز و یک خانم نیازه) اینا رو از دل دیتابیس می‌کشه بیرون و متن هم از نتیج خروجی که احتمالا یه لیست از آبجکت کالا است بسازه که: فلانی‌جون اگر اینو اونو اون‌یکی رو ست کنی برای پاییز خوبه و به بودجه‌ات هم می‌خوره!
🧞♂️ این یه روزی جادو بود، یه روز رویا بود، یه روز محال بود؛ الان با وجود امکانات ساختاری وکتورها و کتابخونه‌ها به راحتی شدنیه، حتی با تغییرات کم در کدهای فعلی!
این Semantic Kernel در حقیقت یه پُله بین دنیای برنامه‌نویسی سنتی و مدل‌های زبانی بزرگ (LLM).
فعلا هم با زبون‌های C#، Python و Java قابل استفاده است. یه لایه‌ی میانی که درخواست‌های مدل‌های AI رو به توابع تعریف‌شده توی کد ترجمه میکنه و پاسخ‌ها را مدیریت میکنه (تبدیل متن به یه کلاس، و ساخت متن با استفاده از دیتای ساختاریافته).
مدل‌های هوش مصنوعی مثل GPT و DALL-E و… تحول بزرگی توی نحوه تعامل ما با نرم‌افزار ایجاد کردن. اما استفاده از این مدل‌ها توی محیط‌های واقعی چالش‌هایی هم داره:
و Semantic Kernel برای پاسخ به این چالش‌ها طراحی شد؛ و هدفش ساده‌سازی یکپارچه‌سازی هوش مصنوعی در پروژه‌های واقعیه.
- ایجاد ربات‌ها و عامل‌های هوشمند: مثل چت‌بات‌هایی که به‌صورت پویا تصمیم می‌گیرن یا فرآیندها رو خودکار می‌کنن.
- یکپارچه‌سازی آسون با کد موجود: با استفاده از قابلیت Function Calling، میشه مدل‌های AI رو به کدهای موجود متصل کرد.
- اتوماسیون فرآیندهای کسب‌وکار: مثل پردازش خودکار درخواست‌های مشتری‌ها یا مدیریت منابع سازمانی.
- مدیریت آسون هوش مصنوعی: فراهم کردن قابلیت مشاهده و نظارت بر عملکرد مدل‌های مختلف.
- اتصال به مدل‌های مختلف AI (مثل OpenAI، یا مدل‌هایی که روی ماشین خودتون دارید)
- پشتیبانی از Vector Storeها
ری‌اکشن 🤓
Please open Telegram to view this post
VIEW IN TELEGRAM
🤓18👍7