Dev Perfects
40 subscribers
9.23K photos
1.26K videos
468 files
13K links
بخوام خیلی خلاصه بگم
این کانال میاد مطالب کانالای خفن تو حوزه تکنولوژی و برنامه نویسی رو جمع میکنه

پست پین رو بخونید
https://t.iss.one/dev_perfects/455


ارتباط:
https://t.iss.one/HidenChat_Bot?start=936082426
Download Telegram
Forwarded from Python Hints
توی معماری سیستم یک اصطلاحی داریم به اسم؛
distributed monolithic
که خب یک anti-pattern هست برای معماری micro-service اول هفته با یک شرکتی برای مشاوره صحبت کردیم (کارشون رو قبول نکردم ولی یک قرارداد کوچک بستم برای اینکه بگم مشکل فعلی سیستم کجاس)

معماری سیستم مثلاً قرار بوده micro-service باشه؛ در نگاه اول هم هست و حتی از تمام ابزارهای لازم هم داره استفاده می‌شه اما به اشتباه.

کل سیستم رو امروز کنار هم چیدم و روی یک سرور بالا آوردم (بجای چندتا سرور) و تبدیلش کردم به multi app monolithic اولش خیلی ناراحت و نگران بودند که پرفورمنس خراب میشه و ازین حرفا ولی بعد توی تست‌ها دیدند که حداقل ۲ برابر سرعت پاسخ و تعداد درخواست‌هایی که هندل میشه بیشتره.

البته من مطمئن بودم که اینطوری می‌شه به سه دلیل :
۱- به وضوح anti pattern رو می‌دیدم
۲- تعداد درخواست‌های بین سرویس‌ها زیاد بود
۳- خیلی از زمان پروفایلنگ، برای درخواست بین سرویس‌ها هدر می‌رفت روی نتورک. (که خب حتی async هم نبود که حداقل cpu هدر نره)

این موضوع دلیلی شد؛ بیام چندتا تعریف اشتباه که دائم می‌شنوم رو انتقال بدم:

۱- توی ماکروسرویس هر سرویس باید دیتابیس جدا داشته باشه.

این تعریف درسته، اما تفسیر غلط ازش زیاده؛ مثلاً ۹۹٪ فکر می‌کنند این یعنی برای هر سرویس باید یک سرور Postgres جدا داشته باشند، نه لزوماً مفهوم این تعریف اینه که:
مثلاً سرویس auth شما نره دیتای سرویس payment رو بخونه حتی اگر جفتشون روی یک دیتابیس هستند (فقط دوتا تیبل جداشده) و برای گرفتن دیتای مورد نیازش به سرویس payment درخواست بده

۲- هر تابع، متد یا ... باید single responsibility داشته باشه.

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

اینو دیدم که میگم، به طرف میگم، خب عالی توابع اینکارها رو بذار یک‌جا داخل یک تابع و درخواست بده اگر مشکلی توی پرداخت پیش اومد همه باهم باید rollback بخوره (توجه به بحث قبل شما حق نداری، تیبل سرویس‌های دیگه رو دستکاری کنی)؛ برگشته می‌گه پس Single Responsiblity چی می‌شه ؟

یک ساعت داشتم براش توضیح میدم؛ که این تابع SRP رو رعایت می‌کنه چون تو فقط داری میگی من پول رو پرداخت کردم موفق بود یا نه.


۳- ماکروسرویس بهتره ...

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


چندتا برداشت اشتباه دیگه هم بود که متأسفانه یادم نیست دیگه،‌ ولی تبدیل سیستم به یک monolithic واقعی توی این پروژه نتایج خیلی بهتری داشت.
حتی برای مرحله بعدی هم پیشنهاد کردم اول سراغ
Load balance
و بالا آوردن چندتا instance از همین monolithic برند، بعد برای تبدیل به micro-sercive از یکی که معماری رو واقعاً بلد هست کمک بگیرند نه کسی که پوشه پوشه کردن فایلای پایتونش رو فقط یاد گرفته.


نهایتاً؛ البته من می‌دونم خیلی از این برداشت‌های اشتباه از کجا میاد.
منابع ترجمه شده به فارسی.

ترجمه اشتباه لغوی یک کلمه، باعث میشه معنی یک جمله بطور کامل عوض بشه.
Forwarded from SoniaCircuit (Sonia Fatholahi)
فاتحه رو باید خوند 😂
اخیراً برای ساخت پنل کاربری در یکی از پروژه‌هام از Filament استفاده کردم و تجربه متفاوتی بود.
برخلاف AdminLTE که نیاز به شخصی‌سازی سنگین دارن، Filament روی لاراول با چند خط کد یه پنل کامل بهم داد؛
مثلا با دستور make:filament-resource نه‌تنها CRUD مدل ساخته می‌شه، بلکه فرم‌ها، جدول‌ها، فیلترها و حتی bulk action ها رو به‌صورت پیش‌فرض برات می‌سازه.
چیزی که برای من جذاب بود، هماهنگی مستقیم Filament با Policies لاراول و همینطور پشتیبانی از Spatie Permission برای role/permission بود؛ یعنی می‌تونید به‌جای workaround، امنیت و سطح دسترسی رو طبق best practice خود لاراول پیاده کنید.
برای دولوپرهای جوونیور و میدلول، کار با Filament بهترین فرصت برای لمس معماری تمیز، درک بهتر authorization و ساخت سریع feature های واقعی توی پروژه‌های production هست.

@DevTwitter | <ehsan azizi/>
Forwarded from محتوای آزاد سهراب (Sohrab)
نام‌بان جدید رو شاهد هستید.



@SohrabContents
Forwarded from محتوای آزاد سهراب (Sohrab)
Forwarded from محتوای آزاد سهراب (Sohrab)
Forwarded from Linuxor ?
پس‌کوچه اخیرا Baba VPN و Giti VPN رو به‌عنوان دو #فیلترشکن ناامن یا مشکوک معرفی کرده. این برنامه‌ها از طریق گوگل‌پلی عرضه شدن و آمار نصب بالایی دارن، که نقص‌ها و حفره‌های امنیتی اونها کاربران زیادی رو در معرض خطر قرار داده.

برنامه‌های دیگری رو هم در بررسی‌های قبلی به‌عنوان ناامن یا مشکوک معرفی کرده بودن، که توصیه میشه احتیاط کنید:
KLID SABZ VPN / Verde VPN / Azad VPN / Canary VPN / Agile VPN / Golnar VPN / Dali VPN / Sai VPN / Bonbast VPN / HaloVPN / Rooz VPN / Tiger VPN / Ultraunique VPN / Alvand VPN / V2ray VPN / Bean VPN / 77 VPN / Ram VPN / Hula VPN / JumpJump VPN ...

🔍 ircf.space
@ircfspace
#گزارش
کلودفلر در هفته‌های اخیر تغییراتی اعمال کرده که بخش بزرگی از کاربران را تحت تأثیر قرار داده. این تغییرات ابتدا با محدودسازی Workers آغاز شد، اما خیلی زود دامنه آن به پروکسی‌های ساده پشت CDN مانند WebSocket و gRPC هم رسید. نتیجه این سیاست‌ها برای مهساسرور جهش بی‌سابقه در حجم ترافیک، فشار سنگین بر کانفیگ‌های غیرورکری و افزایش گزارش‌های Abuse برای دامنه‌ها بود.

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

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

متن کامل گزارش:
👉 mahsanet.com/fa/blog/11/new-cloudflare-limitations

🔍 ircf.space
@ircfspace
Forwarded from Reza Jafari
نگاهی بر مقاله تازه انویدیا، چرا آینده Agentic AI دست مدل‌های کوچیکه؟

ین روزها بحث زیادی هست که آینده‌ی Agentic AI نه با مدل‌های خیلی بزرگ (LLM) بلکه با مدل‌های کوچک‌تر یا همون SLM‌ها رقم می‌خوره. مقاله‌ی تازه‌ای هم از شرکت NVIDIA منتشر شده که دقیقاً همین موضوع رو توضیح می‌ده و سه دلیل اصلی براش میاره: قدرت کافی، صرفه‌جویی اقتصادی و انطباق عملیاتی.

اول از نظر قدرت. خیلی‌ها تصور می‌کنن برای ساخت یک ایجنت همیشه باید از یک مدل خیلی عظیم استفاده کنیم، اما واقعیت اینه که بیشتر کارهایی که یک ایجنت انجام می‌ده چندان پیچیده نیست. عمده‌ی وظایف به انتخاب ابزار مناسب برمی‌گرده؛ یعنی تصمیم بگیره از بین چند ابزار، کدوم یکی باید به‌کار گرفته بشه. این در عمل شبیه یک مسئله‌ی دسته‌بندی (classification) هست، نه نوشتن مقاله‌ی طولانی یا حل یک معادله‌ی سخت. ایجنت‌ها بیشتر به توانایی‌هایی مثل دنبال‌کردن دستورالعمل‌ها، تولید کدهای کوتاه، استدلال ساده و درک متن نیاز دارن. بنابراین به‌کارگیری یک مدل غول‌آسا برای چنین کاری مثل اینه که برای دوختن یک لباس سوزن بخوای از شمشیر استفاده کنی.

از نظر اقتصادی، تفاوت‌ها چشمگیره. اجرای یک مدل ۷ میلیارد پارامتری بین ۱۰ تا ۳۰ برابر ارزون‌تر از اجرای یک مدل ۷۰ میلیاردی تموم می‌شه. این تفاوت فقط در هزینه‌ی سخت‌افزار و سرویس‌های ابری نیست، بلکه مصرف انرژی کمتر، نیاز به زیرساخت سبک‌تر و حتی امکان اجرا روی دستگاه‌های لوکال مثل رایانه‌ی شخصی یا لپ‌تاپ رو هم شامل می‌شه. علاوه بر این، چون SLMها کوچک‌تر هستن، آموزش و فاین‌تیون کردن‌شون داده و زمان کمتری لازم داره. همین موضوع باعث می‌شه چرخه‌ی آزمایش و بهبود خیلی سریع‌تر پیش بره و توسعه‌دهنده‌ها راحت‌تر ایده‌هاشون رو امتحان کنن. به بیان ساده، این مدل‌ها ماژولار و قابل تعویض هستن و هزینه‌ی تکرار و آزمایش رو پایین می‌آرن.

از نظر انطباق عملیاتی هم SLMها برتری‌های مهمی دارن. ایجنت‌ها معمولاً فقط از بخش کوچکی از قابلیت‌های LLM استفاده می‌کنن. مثلاً تولید یک خروجی JSON تمیز یا برقراری ارتباط درست با یک API. در این موارد، مدل‌های کوچک‌تر هم دقیق‌تر و هم مطمئن‌تر عمل می‌کنن. یکی از مشکلات مدل‌های بزرگ، خطاهای موسوم به «توهم» یا همون hallucination هست. اما SLMها چون برای وظایف محدودتر آموزش می‌بینن، خروجی‌شون سازگارتر و قابل اعتمادتره. نتیجه اینه که فرمت خروجی ثابت می‌مونه، ابزار و کد راحت‌تر یکپارچه می‌شن و ارتباط با APIها بدون خطا انجام می‌شه. NVIDIA حتی پیشنهاد داده که بهترین روش استفاده‌ی ترکیبیه: یعنی LLM برای مرحله‌ی برنامه‌ریزی و SLM برای مرحله‌ی اجرا. اینطوری هم قدرت استدلال مدل بزرگ رو داری و هم سرعت و دقت مدل کوچک رو.

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

با وجود این همه مزایا، هنوز خیلی از شرکت‌ها سراغ مدل‌های بزرگ می‌رن. دلیل اصلی هم سرمایه‌گذاری‌های سنگین روی زیرساخت‌های LLM و همین‌طور نوع معیارهایی هست که برای ارزیابی SLM استفاده می‌شه. معمولاً این ارزیابی‌ها روی توانایی‌های خیلی پیچیده مثل استدلال چندمرحله‌ای متمرکز هستن، در حالی که معیار واقعی در Agentic AI باید چیزهایی مثل دقت در انتخاب ابزار یا پایداری تعامل با API باشه.

در نهایت می‌شه گفت که SLMها هم قدرت کافی دارن، هم اقتصادی هستن و هم عملیاتی. ایجنت‌ها بیشتر از همه به دقت، تمرکز و سازگاری نیاز دارن، نه به یک مدل همه‌فن‌حریف. بنابراین آینده‌ی Agentic AI نه با مدل‌های غول‌آسا و پرهزینه، بلکه با مدل‌های کوچک، تخصصی و ماژولار ساخته خواهد شد.

🔤🔤🔤🔤🔤🔤🔤

🥇 اهورا اولین اپراتور هوش مصنوعی راهبردی ایران در حوزه ارائه خدمات و سرویس‌های زیرساخت هوش مصنوعی

🛍کد تخفیف ۱۰ درصدی محصولات اهورا برای اعضای کانال
AHURA5

🌐 لینک وب‌سایت اهورا

@reza_jafari_ai
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from a pessimistic researcher (Kc)
فرازی از بیوگرافی آقای Apt ( متن کپی شده از روی وب‌سایتشون )

Krzysztof Apt studied mathematics in Wroclaw, Poland and got his PhD in mathematical logic in 1974, in Warsaw, Poland. "But the communism was not a very inspiring political system so already in the Fall of 1974 I voted with my feet and left the country for good", he explains. "It was not easy in those times of bipolar world to settle down abroad, but somehow I succeeded without giving up my interest in science. I learned computer science and more recently, game theory, so to say, 'on the street', which was possible because of my background in mathematics."
هر روز که میگذره MCP داره بیشتر و بیشتر پر اهمیت میشه تو دنیای LLM ها.

و الان هم Openai داره داخل Chatgpt قابلیت اتصال به MCP شخصی رو تست میکنه و در اختیار DEV ها قرار میده.

اگر هنوز از MCP اطلاعی ندارید این راهنمای ۵ دقیقه ای ماکس ایده خوبی به شما میده

https://maux.site/learn/mcp

@DevTwitter | <Mani/>
Forwarded from a pessimistic researcher (Kc)
کوله
Forwarded from a pessimistic researcher (Kc)
کاش می‌فهمیدم که از این زندگی چی میخوام و دنبال چی‌ام
Forwarded from 🎄 یک برنامه نویس تنبل (Lazy 🌱)
🔶 قانون شماره 1 در محل کار من

@TheRaymondDev
Forwarded from 🎄 یک برنامه نویس تنبل (Lazy 🌱)
🔶 قانون شماره 1 در محل کار

@TheRaymondDev
Forwarded from Linuxor ?
پی وی منو سوارخ کردین انقدر گفتین فیگما خوبه یاد بگیریم!! فیگما غلط کرد شمارو پول دار کنه، فیگما چیه اصلا؟ فیگما یه ابزار و محیطه فقط؛ چیزی که شمارو پول دار میکنه مهارت های UI/UX هست که اونقدری تجربش پیر کنندس فکر نکنم حوصله داشته باشید بعدش بیاید توییتر خوشحالیتون رو با مردم عادی جشن بگیرید؛ خوشحالیش رو باید با تک تک سلول های پیر شدتون جشن بگیرید.


@Linuxor