چهار استراتژی کلیدی برای مقیاسپذیری مؤثر پایگاه داده
با رشد سیستمها و افزایش تعداد کاربران، پایگاه داده به یکی از حساسترین و چالشبرانگیزترین بخشهای معماری نرمافزار تبدیل میشود. انتخاب رویکرد مناسب برای مقیاسپذیری، نقش مهمی در حفظ کارایی، پایداری و در دسترسپذیری سرویس دارد. در این مقاله، چهار استراتژی رایج و اثربخش برای مقیاسپذیری پایگاه داده را بررسی میکنیم.
۱) استراتژی Vertical Scaling (افزایش ظرفیت سختافزاری)
سادهترین روش برای افزایش توان پردازشی پایگاه داده، ارتقای منابع سختافزاری نظیر CPU، RAM و فضای ذخیرهسازی است.
این رویکرد بدون نیاز به تغییرات ساختاری در نرمافزار انجام میشود و در بسیاری از سیستمها، اولین گام منطقی برای افزایش ظرفیت به شمار میآید.
با این حال، Vertical Scaling دارای محدودیت ذاتی است و نهایتاً تا سقف مشخصی قابل افزایش است.
۲) استراتژی Replication (توزیع بار خواندن)
در Replication با ایجاد نسخههای متعدد از داده، امکان توزیع بار خواندن بین چندین نود را فراهم میسازد.
در این مدل:
عملیات نوشتن تنها به یک نود Leader ارسال میشود، Leader تغییرات را به نودهای Follower منتقل میکند، عملیات خواندن میتواند توسط هر یک از نودهای Leader یا Follower انجام شود.
هدف اصلی این روش افزایش ظرفیت Read و بهبود کارایی سامانه در مواجهه با تعداد زیاد درخواستهای خواندن است.
۳) استراتژی Caching (افزایش سرعت با ذخیرهسازی موقت)
استفاده از Cache، از تکرار درخواستهای غیرضروری به پایگاه داده جلوگیری میکند.
در این رویکرد، نخستین درخواست داده را از پایگاه داده دریافت کرده و نتیجه آن در Cache ذخیره میشود.
درخواستهای بعدی، در صورت وجود داده در Cache، بهسرعت پاسخ داده میشوند.
این روش علاوه بر کاهش بار پایگاه داده، بهطور چشمگیری سرعت پاسخگویی را نیز افزایش میدهد.
۴) استراتژی Partitioning / Sharding (مقیاسپذیری افقی برای مدیریت بار نوشتن)
استراتژی Sharding با تقسیم داده به بخشهای مستقل (Partitions یا Shards) و توزیع آنها در چندین سرور، امکان افزایش ظرفیتپذیری عملیات نوشتن را فراهم میکند.
در این مدل:
هر شارد بخشی از داده را مدیریت میکند،
هر درخواست نوشتن تنها به شارد مربوطه ارسال میشود،
بار نوشتن میان چندین ماشین تقسیم میگردد.
این رویکرد برای سامانههایی که حجم عملیات نوشتن آنها بالا است، روشی پایدار و قابل اعتماد به حساب میآید.
ارتباط Replication و Sharding
در معماریهای بزرگ، Sharding و Replication معمولاً بهصورت ترکیبی مورد استفاده قرار میگیرند.
هر شارد روی چندین نود Replicate میشود تا در صورت خرابی یک نود، دسترسپذیری داده حفظ گردد.
جمعبندی
چهار روش Vertical Scaling، Replication، Caching و Sharding، ستونهای اصلی مقیاسپذیری پایگاه داده در معماریهای مدرن محسوب میشوند.
انتخاب مناسب میان این روشها به نیازهای عملکردی، حجم داده، الگوی دسترسی و محدودیتهای معماری هر سیستم بستگی دارد.
بهکارگیری درست و ترکیبی این استراتژیها، امکان ساخت سامانههایی پایدار، سریع و قابلاتکا را فراهم میکند.
@DevTwitter | <Amir Rahimi Nejad/>
با رشد سیستمها و افزایش تعداد کاربران، پایگاه داده به یکی از حساسترین و چالشبرانگیزترین بخشهای معماری نرمافزار تبدیل میشود. انتخاب رویکرد مناسب برای مقیاسپذیری، نقش مهمی در حفظ کارایی، پایداری و در دسترسپذیری سرویس دارد. در این مقاله، چهار استراتژی رایج و اثربخش برای مقیاسپذیری پایگاه داده را بررسی میکنیم.
۱) استراتژی Vertical Scaling (افزایش ظرفیت سختافزاری)
سادهترین روش برای افزایش توان پردازشی پایگاه داده، ارتقای منابع سختافزاری نظیر CPU، RAM و فضای ذخیرهسازی است.
این رویکرد بدون نیاز به تغییرات ساختاری در نرمافزار انجام میشود و در بسیاری از سیستمها، اولین گام منطقی برای افزایش ظرفیت به شمار میآید.
با این حال، Vertical Scaling دارای محدودیت ذاتی است و نهایتاً تا سقف مشخصی قابل افزایش است.
۲) استراتژی Replication (توزیع بار خواندن)
در Replication با ایجاد نسخههای متعدد از داده، امکان توزیع بار خواندن بین چندین نود را فراهم میسازد.
در این مدل:
عملیات نوشتن تنها به یک نود Leader ارسال میشود، Leader تغییرات را به نودهای Follower منتقل میکند، عملیات خواندن میتواند توسط هر یک از نودهای Leader یا Follower انجام شود.
هدف اصلی این روش افزایش ظرفیت Read و بهبود کارایی سامانه در مواجهه با تعداد زیاد درخواستهای خواندن است.
۳) استراتژی Caching (افزایش سرعت با ذخیرهسازی موقت)
استفاده از Cache، از تکرار درخواستهای غیرضروری به پایگاه داده جلوگیری میکند.
در این رویکرد، نخستین درخواست داده را از پایگاه داده دریافت کرده و نتیجه آن در Cache ذخیره میشود.
درخواستهای بعدی، در صورت وجود داده در Cache، بهسرعت پاسخ داده میشوند.
این روش علاوه بر کاهش بار پایگاه داده، بهطور چشمگیری سرعت پاسخگویی را نیز افزایش میدهد.
۴) استراتژی Partitioning / Sharding (مقیاسپذیری افقی برای مدیریت بار نوشتن)
استراتژی Sharding با تقسیم داده به بخشهای مستقل (Partitions یا Shards) و توزیع آنها در چندین سرور، امکان افزایش ظرفیتپذیری عملیات نوشتن را فراهم میکند.
در این مدل:
هر شارد بخشی از داده را مدیریت میکند،
هر درخواست نوشتن تنها به شارد مربوطه ارسال میشود،
بار نوشتن میان چندین ماشین تقسیم میگردد.
این رویکرد برای سامانههایی که حجم عملیات نوشتن آنها بالا است، روشی پایدار و قابل اعتماد به حساب میآید.
ارتباط Replication و Sharding
در معماریهای بزرگ، Sharding و Replication معمولاً بهصورت ترکیبی مورد استفاده قرار میگیرند.
هر شارد روی چندین نود Replicate میشود تا در صورت خرابی یک نود، دسترسپذیری داده حفظ گردد.
جمعبندی
چهار روش Vertical Scaling، Replication، Caching و Sharding، ستونهای اصلی مقیاسپذیری پایگاه داده در معماریهای مدرن محسوب میشوند.
انتخاب مناسب میان این روشها به نیازهای عملکردی، حجم داده، الگوی دسترسی و محدودیتهای معماری هر سیستم بستگی دارد.
بهکارگیری درست و ترکیبی این استراتژیها، امکان ساخت سامانههایی پایدار، سریع و قابلاتکا را فراهم میکند.
@DevTwitter | <Amir Rahimi Nejad/>
👍13❤6🔥2
چرا هنوز وردپرس باید اینقدر “دکمهمحور” و “فرممحور” باشه؟
چرا کاربر نتونه مثل حرف زدن با یه آدم، با سایت حرف بزنه و سایت هم واقعا بفهمه چی میگه؟
خب با NLWeb میشه ولی باید مفهوم عمیقتری رو بررسی کنیم اون هم پایه این دانش یا بهتره بگم مادرش یعنی NLU (Natural Language Understanding) ، میشه وردپرس رو از یه CMS معمولی تبدیل کرد به یه موجود فهمنده ( البته درنظر بگیرید منظورمون استفاده از یک چت بات chatbot هوشمند یا متصل به یک هوش مصنوعی نیست ) در حقیقت باید یک لایه ای در خود وردپرس ایجاد کنیم که بتونه نیت کاربر رو برداشت کنه و کاری که باید رو انجام بده؟
دیدم نه فقط میشه، بلکه ترکیب وردپرس با NLU دقیقا همون جهتیه که وب باید بره.
همه چیز از همین سؤال ساده شروع شد:
اگه کاربر به جای پر کردن فرم پیچیده پشتیبانی، فقط بگه «میخوام اشتراک سایتم رو تمدید کنم»، چرا سایت نفهمه؟
اینجا بیشتر بخونید در موردش دو منبع نسبتا خوب و کاربردی :
https://fastbots.ai/blog/nlu-for-beginners-a-step-by-step-guide
https://botpenguin.com/glossary/natural-language-understanding
اگه مدیر سایت بخواد بدون رفتن به پنل، فقط تو یه چت بگه «تمام محصولات ناموجود رو منتشر نکن»، چرا این با لایهی زبان طبیعی اجرا نشه؟
از همینجا به بعد، ایده تبدیل شد به یک مسیر جدی:
وردپرس + NLU
یعنی اضافه کردن یک مغز فهمنده که بتونه Intent کاربر رو انتخاب کنه، Entityها رو دربیاره و در نهایت، یک ACTION واقعی سمت وردپرس اجرا کنه.
به نظرم این، همون نقطه تحولیه که وردپرس چند ساله کم داشته: رفتن از “کلیک کردن” به “درک کردن”.
دارم روی یک معماری کار میکنم که این دو دنیا رو به هم قفل کنه:
1- پشتصحنه پایتون برای پردازش زبان طبیعی
2- جلوی صحنه وردپرس
3- یک لایه میانی که اینها رو مثل یک سیستم عصبی واقعی به هم وصل کنه.
فعلا هدفم معرفی این نگاهه، نه آموزش دادن و شروع پروژه.
چون معتقدم این مدل سیستمها از این به بعد بخش جدی دنیای وب میشن.
نه فقط برای تجربه کاربری، بلکه برای اتوماسیون، مدیریت هوشمند، و حتی تصمیمگیری درون سایت.
بهزودی روی این ایده کار عمیقتر میکنم و نتایجش رو منتشر میکنم.
هم برای کسانی که دنبال ساخت سرویسهای هوشمند روی وردپرسن
و هم برای کسایی که میخوان از پایتون استفاده کنن تا یک CMS معمولی رو تبدیل به یک سیستم عامل هوشمند وب کنن.
این فقط یه آموزش نیست…
این شروع یک تحول و تغییر جهته.
@DevTwitter | <amin diba/>
چرا کاربر نتونه مثل حرف زدن با یه آدم، با سایت حرف بزنه و سایت هم واقعا بفهمه چی میگه؟
خب با NLWeb میشه ولی باید مفهوم عمیقتری رو بررسی کنیم اون هم پایه این دانش یا بهتره بگم مادرش یعنی NLU (Natural Language Understanding) ، میشه وردپرس رو از یه CMS معمولی تبدیل کرد به یه موجود فهمنده ( البته درنظر بگیرید منظورمون استفاده از یک چت بات chatbot هوشمند یا متصل به یک هوش مصنوعی نیست ) در حقیقت باید یک لایه ای در خود وردپرس ایجاد کنیم که بتونه نیت کاربر رو برداشت کنه و کاری که باید رو انجام بده؟
دیدم نه فقط میشه، بلکه ترکیب وردپرس با NLU دقیقا همون جهتیه که وب باید بره.
همه چیز از همین سؤال ساده شروع شد:
اگه کاربر به جای پر کردن فرم پیچیده پشتیبانی، فقط بگه «میخوام اشتراک سایتم رو تمدید کنم»، چرا سایت نفهمه؟
اینجا بیشتر بخونید در موردش دو منبع نسبتا خوب و کاربردی :
https://fastbots.ai/blog/nlu-for-beginners-a-step-by-step-guide
https://botpenguin.com/glossary/natural-language-understanding
اگه مدیر سایت بخواد بدون رفتن به پنل، فقط تو یه چت بگه «تمام محصولات ناموجود رو منتشر نکن»، چرا این با لایهی زبان طبیعی اجرا نشه؟
از همینجا به بعد، ایده تبدیل شد به یک مسیر جدی:
وردپرس + NLU
یعنی اضافه کردن یک مغز فهمنده که بتونه Intent کاربر رو انتخاب کنه، Entityها رو دربیاره و در نهایت، یک ACTION واقعی سمت وردپرس اجرا کنه.
به نظرم این، همون نقطه تحولیه که وردپرس چند ساله کم داشته: رفتن از “کلیک کردن” به “درک کردن”.
دارم روی یک معماری کار میکنم که این دو دنیا رو به هم قفل کنه:
1- پشتصحنه پایتون برای پردازش زبان طبیعی
2- جلوی صحنه وردپرس
3- یک لایه میانی که اینها رو مثل یک سیستم عصبی واقعی به هم وصل کنه.
فعلا هدفم معرفی این نگاهه، نه آموزش دادن و شروع پروژه.
چون معتقدم این مدل سیستمها از این به بعد بخش جدی دنیای وب میشن.
نه فقط برای تجربه کاربری، بلکه برای اتوماسیون، مدیریت هوشمند، و حتی تصمیمگیری درون سایت.
بهزودی روی این ایده کار عمیقتر میکنم و نتایجش رو منتشر میکنم.
هم برای کسانی که دنبال ساخت سرویسهای هوشمند روی وردپرسن
و هم برای کسایی که میخوان از پایتون استفاده کنن تا یک CMS معمولی رو تبدیل به یک سیستم عامل هوشمند وب کنن.
این فقط یه آموزش نیست…
این شروع یک تحول و تغییر جهته.
@DevTwitter | <amin diba/>
👍24🍌15❤3🔥1
چند وقت پیش وسط یه پروژه معمولی بودم. یه سایت ساده که فقط باید اطلاعات رو درست و تمیز نشون بده. همون موقع یه سؤال تو ذهنم چرخید:
اصلاً چرا وب هنوز اینقدر یکطرفهس؟
چرا سایت فقط نشون میده ولی نمیفهمه چی میخوای؟
از همین سؤال رسیدم به چیزی که این روزا داره یه لایه جدید به وب اضافه میکنه: NLWeb
چرا NLWeb اینقدر باحاله؟
ایدهاش خیلی سادهس ، اینکه هر سایت بتونه تبدیل بشه به یه رابط گفتگویی واقعی.
نه چتباتهای معمولی؛ یه چیزی شبیه یه دستیار که واقعاً محتوای سایت رو درک میکنه.
وقتی این قضیه رو با پایتون ترکیب میکنی، ماجرا جذابتر هم میشه:
اطلاعات سایت تبدیل میشن به بردارهای قابل جستجوی معنایی
پایتون میشه مغز تحلیل و اتصال به مدلهای زبانی
همهچی همزمان اتفاق میفته، بدون شلوغکاری
خروجی چی میشه؟
کاربر که وارد سایت میشه، دیگه مجبور نیست تو منوها یا PDFهای سنگین دنبال جواب بگرده.
فقط سؤالش رو مینویسه و پشتصحنه، NLWeb کل محتوای سایت رو میفهمه، تحلیل میکنه و یه جواب دقیق و تمیز میده.
https://github.com/nlweb-ai/NLWeb
یعنی در عمل:
سایتها از یه مشت صفحه ثابت، تبدیل میشن به یه موجود زنده که کاربر رو میفهمه
تجربه از «جستجو» میره سمت «گفتگو»
برندها یه لایه تعامل هوشمند و واقعی میگیرن
دنیای وب و برنامه نویسی هوشمندگرا ، کمکم داره از حالت نمایشی، میره سمت فهمیدن و این فقط شروعشه.
@DevTwitter | <amin diba/>
اصلاً چرا وب هنوز اینقدر یکطرفهس؟
چرا سایت فقط نشون میده ولی نمیفهمه چی میخوای؟
از همین سؤال رسیدم به چیزی که این روزا داره یه لایه جدید به وب اضافه میکنه: NLWeb
چرا NLWeb اینقدر باحاله؟
ایدهاش خیلی سادهس ، اینکه هر سایت بتونه تبدیل بشه به یه رابط گفتگویی واقعی.
نه چتباتهای معمولی؛ یه چیزی شبیه یه دستیار که واقعاً محتوای سایت رو درک میکنه.
وقتی این قضیه رو با پایتون ترکیب میکنی، ماجرا جذابتر هم میشه:
اطلاعات سایت تبدیل میشن به بردارهای قابل جستجوی معنایی
پایتون میشه مغز تحلیل و اتصال به مدلهای زبانی
همهچی همزمان اتفاق میفته، بدون شلوغکاری
خروجی چی میشه؟
کاربر که وارد سایت میشه، دیگه مجبور نیست تو منوها یا PDFهای سنگین دنبال جواب بگرده.
فقط سؤالش رو مینویسه و پشتصحنه، NLWeb کل محتوای سایت رو میفهمه، تحلیل میکنه و یه جواب دقیق و تمیز میده.
https://github.com/nlweb-ai/NLWeb
یعنی در عمل:
سایتها از یه مشت صفحه ثابت، تبدیل میشن به یه موجود زنده که کاربر رو میفهمه
تجربه از «جستجو» میره سمت «گفتگو»
برندها یه لایه تعامل هوشمند و واقعی میگیرن
دنیای وب و برنامه نویسی هوشمندگرا ، کمکم داره از حالت نمایشی، میره سمت فهمیدن و این فقط شروعشه.
@DevTwitter | <amin diba/>
🔥34❤9👍6🍌6
گاهی تو دنیای فرانتاند یه چیزهایی هست که همیشه فقط موقع مصاحبه سر و کلهشون پیدا میشه…
«خب بگو ببینم Closure چیه؟»
ولی واقعیت اینه که Closure یکی از بنیادیترین مفاهیمی هست که خیلی از طراحیها و معماریهای مدرن جاوااسکریپت، و حتی خود React، روی اون سوار شدهاند.
توی این مقاله، سعی کردم خیلی ساده و مرحلهبهمرحله نشون بدم:
کلوژر واقعاً چیه و چرا مهمه
کجاها تو طراحی نرمافزار ازش استفاده میکنیم
چه معضلاتی میتونه به همراه داشته باشه
و مهمتر از همه: چطور React با استفاده خلاقانه از Closure، هوکهایی مثل useState و useEffect رو ممکن میکنه
برای اینکه مفهوم واقعاً جا بیفته، خودمون هم یک نسخهی مینیمال و واقعی از useState و useEffect رو با Closure ساختیم تا ببینیم پشتپرده چه خبره!
اگه Closure همیشه برات یک چیز مبهم، ترسناک یا فقط یک سؤال مصاحبهای بوده، این مقاله نگاهت رو بهش کامل عوض میکنه.
لینک مقاله
https://medium.com/@ajblog7070/how-javanoscript-closures-power-react-re-creating-usestate-and-useeffect-from-scratch-16a7ee0a0757
@DevTwitter | <Ali Jafarian/>
«خب بگو ببینم Closure چیه؟»
ولی واقعیت اینه که Closure یکی از بنیادیترین مفاهیمی هست که خیلی از طراحیها و معماریهای مدرن جاوااسکریپت، و حتی خود React، روی اون سوار شدهاند.
توی این مقاله، سعی کردم خیلی ساده و مرحلهبهمرحله نشون بدم:
کلوژر واقعاً چیه و چرا مهمه
کجاها تو طراحی نرمافزار ازش استفاده میکنیم
چه معضلاتی میتونه به همراه داشته باشه
و مهمتر از همه: چطور React با استفاده خلاقانه از Closure، هوکهایی مثل useState و useEffect رو ممکن میکنه
برای اینکه مفهوم واقعاً جا بیفته، خودمون هم یک نسخهی مینیمال و واقعی از useState و useEffect رو با Closure ساختیم تا ببینیم پشتپرده چه خبره!
اگه Closure همیشه برات یک چیز مبهم، ترسناک یا فقط یک سؤال مصاحبهای بوده، این مقاله نگاهت رو بهش کامل عوض میکنه.
لینک مقاله
https://medium.com/@ajblog7070/how-javanoscript-closures-power-react-re-creating-usestate-and-useeffect-from-scratch-16a7ee0a0757
@DevTwitter | <Ali Jafarian/>
❤24👍4🔥2
آیا هوش مصنوعی جای همه شغل هارو میگیره؟
نه
آیا توسعه ی نرم افزار از همیشه سخت تر میشه؟
آره
تو دنیایی که همه از هوش مصنوعی صحبت می کنند و دارند ازش استفاده می کنند و شرکت های بزرگ سرمایه گذاری سنگین می کنند، توسعه دهنده نرم افزار شدن سخت تر شده.
اما اگه سیستم رو بفهمی، توانایی debug کردن داشته باشی و بتونی با دلیل مشکلی رو حل کنی همچنان برای تو جا هست.
و اگه به اندازه کافی عمیق شده باشی می تونی پول خوبی در بیاری.
چون هنوز صنعت به نیروی خوب نیاز داره.
به کسی که توانایی فکر کردن و فهمیدن داره.
تجربه ارزش داره، حل کردن مشکل ارزش داره، اینکه یک سیستم چگونه کار می کنه و نه چرا، ارزش داره.
در نهایت برنامه نویس های ضعیف حذف میشن، برنامه نویس های متوسط باید پیشرفت کنن و برنامه نویس های قوی جاشون امنه.
https://www.youtube.com/watch?v=JPuP7SLs44g
@DevTwitter | <Yusof Sadat Fakhr/>
نه
آیا توسعه ی نرم افزار از همیشه سخت تر میشه؟
آره
تو دنیایی که همه از هوش مصنوعی صحبت می کنند و دارند ازش استفاده می کنند و شرکت های بزرگ سرمایه گذاری سنگین می کنند، توسعه دهنده نرم افزار شدن سخت تر شده.
اما اگه سیستم رو بفهمی، توانایی debug کردن داشته باشی و بتونی با دلیل مشکلی رو حل کنی همچنان برای تو جا هست.
و اگه به اندازه کافی عمیق شده باشی می تونی پول خوبی در بیاری.
چون هنوز صنعت به نیروی خوب نیاز داره.
به کسی که توانایی فکر کردن و فهمیدن داره.
تجربه ارزش داره، حل کردن مشکل ارزش داره، اینکه یک سیستم چگونه کار می کنه و نه چرا، ارزش داره.
در نهایت برنامه نویس های ضعیف حذف میشن، برنامه نویس های متوسط باید پیشرفت کنن و برنامه نویس های قوی جاشون امنه.
https://www.youtube.com/watch?v=JPuP7SLs44g
@DevTwitter | <Yusof Sadat Fakhr/>
👍21👎9❤7🔥2
سلام رفقا
چند روزی درگیر طراحی یه اپلیکیشن Shop بودم که داخلش مدیریت نمایندهها هم بهصورت کامل هندل بشه. راستش تو مسیر کلی چالش داشتم و یهسری سؤال بیجواب ذهنمو درگیر کرده بود.
تا اینکه به یه داکیومنت خیلی خفن رسیدم که حتی چندتا از مدیرهای FAANG (Meta(Facebook), Amazon, Apple, Netflix, Google) هم نظر دادن و واقعاً محتوای کامل و کاربردیای داره.
اگه دوست دارید مطالعهاش کنید، از این لینک میتونید برید
https://www.systemdesignhandbook.com/guides/design-inventory-management-system/
@DevTwitter | <rasol kalantari/>
چند روزی درگیر طراحی یه اپلیکیشن Shop بودم که داخلش مدیریت نمایندهها هم بهصورت کامل هندل بشه. راستش تو مسیر کلی چالش داشتم و یهسری سؤال بیجواب ذهنمو درگیر کرده بود.
تا اینکه به یه داکیومنت خیلی خفن رسیدم که حتی چندتا از مدیرهای FAANG (Meta(Facebook), Amazon, Apple, Netflix, Google) هم نظر دادن و واقعاً محتوای کامل و کاربردیای داره.
اگه دوست دارید مطالعهاش کنید، از این لینک میتونید برید
https://www.systemdesignhandbook.com/guides/design-inventory-management-system/
@DevTwitter | <rasol kalantari/>
❤12🍌4🔥1
اگر میخواهید کاری با واتس اپ بکنید برای اتوماسیون
https://github.com/tulir/whatsmeow
متاسفانه این اپ منفور هرچی لینک داره رو demote میکنه
@DevTwitter | <Fred/>
https://github.com/tulir/whatsmeow
متاسفانه این اپ منفور هرچی لینک داره رو demote میکنه
@DevTwitter | <Fred/>
👍13❤6🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
اگر قدرت AI در دستان همه است، مدیون تلاشهای بیوقفه پیشگامانی چون یان لکان هستیم.
این ویدئو سفری ست به سال 1989 (1368)؛روزگاری که جادهها آسفالت نبود و بسیاری از نفت برای گرم کردن استفاده میکردند، پژوهشگران در آمریکا در حال آموزش مدل های AI بینایی ماشین مبتنی بر شبکه عصبی بودند.
@DevTwitter | <Gratomic AI Bot/>
این ویدئو سفری ست به سال 1989 (1368)؛روزگاری که جادهها آسفالت نبود و بسیاری از نفت برای گرم کردن استفاده میکردند، پژوهشگران در آمریکا در حال آموزش مدل های AI بینایی ماشین مبتنی بر شبکه عصبی بودند.
@DevTwitter | <Gratomic AI Bot/>
🔥105❤21👍9👎4
#کوته_نیوز
دیجیاتو/ گوگل دسترسی رایگان به جمینای 3 پرو و Nano Banana Pro را محدود کرد و گفت باید پول بپاشید رو سر و صورتم.
@DevTwitter
دیجیاتو/ گوگل دسترسی رایگان به جمینای 3 پرو و Nano Banana Pro را محدود کرد و گفت باید پول بپاشید رو سر و صورتم.
@DevTwitter
🍌101👍3🔥2❤1
توی vibe coding مرحله planning رو جدی بگیرید تا خروجیتون چند برابر بهتر بهشه.
به صورت خلاصه باید سه مرحله رو طی کنید
۱. تهیه کردن کانتکست خلاصه و درست
از AI توقع نداشته باشید کل پروژه رو تو ذهنش داشته باشه برای هر تسک بهش بگید به کجاها باید توجه کنه و به کجاها توجه نکنه.
کانتکست هم باید کوچیک باشه و هم باید جامع باشه
۲. پلن
هیچقوت از AI نخواید مستقیم کد رو بزنه چون بعدش refine کردنش خیلی سخت میشه. اول بخواید plan کنه اگه plan اون طوری که شما میخواستید نبود ازش بخواید plan رو refine کنه
۳. اجرا و راستی آزمایی.
مرحله آخرم اجراست. اگه اجراش خیلی پرت بود بهتره کل کد رو پاک کنید و برگردید به مرحله ۲ یا حتی مرحله ۱ اینکه هی با پرامپت های بعدی سعی کنید مشکل رو فیکس کنید خیلی جواب نمیده
مثلا فرض کنید شما یه پروژه دارید که تست نداره و با vibe coding میخواید براش تست بنویسید. راه اول اینه که سعی کنید توی یه پرامپت بلند یا کوتاه از AI بخواید برای شما تست بنویسه.
ولی راه پیشنهادی من اینه:
۱. از AI بخواید ماژول های پروژه رو برای شما شناسایی کنه و همراه با جزئیات لازمه نوشته بشه بده و توی یه فایل به هر اسمی مثل TASK1_PLAN.md بریز حالا بررسی نهایی رو روی این فایل بکنید مطمئن بشید best practice هایی که میخواید رعایت بشه توی PLAN نوشته شده اینکه چیا باید ماک بشه چیا نباید بشه اونجا هست و ۳. در قدم نهایی بخواید PLAN رو اجرا کنه
@DevTwitter | <brdia/>
به صورت خلاصه باید سه مرحله رو طی کنید
۱. تهیه کردن کانتکست خلاصه و درست
از AI توقع نداشته باشید کل پروژه رو تو ذهنش داشته باشه برای هر تسک بهش بگید به کجاها باید توجه کنه و به کجاها توجه نکنه.
کانتکست هم باید کوچیک باشه و هم باید جامع باشه
۲. پلن
هیچقوت از AI نخواید مستقیم کد رو بزنه چون بعدش refine کردنش خیلی سخت میشه. اول بخواید plan کنه اگه plan اون طوری که شما میخواستید نبود ازش بخواید plan رو refine کنه
۳. اجرا و راستی آزمایی.
مرحله آخرم اجراست. اگه اجراش خیلی پرت بود بهتره کل کد رو پاک کنید و برگردید به مرحله ۲ یا حتی مرحله ۱ اینکه هی با پرامپت های بعدی سعی کنید مشکل رو فیکس کنید خیلی جواب نمیده
مثلا فرض کنید شما یه پروژه دارید که تست نداره و با vibe coding میخواید براش تست بنویسید. راه اول اینه که سعی کنید توی یه پرامپت بلند یا کوتاه از AI بخواید برای شما تست بنویسه.
ولی راه پیشنهادی من اینه:
۱. از AI بخواید ماژول های پروژه رو برای شما شناسایی کنه و همراه با جزئیات لازمه نوشته بشه بده و توی یه فایل به هر اسمی مثل TASK1_PLAN.md بریز حالا بررسی نهایی رو روی این فایل بکنید مطمئن بشید best practice هایی که میخواید رعایت بشه توی PLAN نوشته شده اینکه چیا باید ماک بشه چیا نباید بشه اونجا هست و ۳. در قدم نهایی بخواید PLAN رو اجرا کنه
@DevTwitter | <brdia/>
1👍54👎13❤9🍌5
مدلی که این روزها توی اخبار خوب دیده نشد مدل ۶ میلیارد پارامتری Z-Image چینی هستش که تصاویر با کیفیتی رو با سرعت بالا (۱ ثانیه!) روی VRAM 16 GB و به صورت لوکال تولید میکنه.
مثل بیشتر مدلهای اوپن سورس چینی، بدون سانسور و محدودیته.
https://github.com/Tongyi-MAI/Z-Image
@DevTwitter | <Diego Jr/>
مثل بیشتر مدلهای اوپن سورس چینی، بدون سانسور و محدودیته.
https://github.com/Tongyi-MAI/Z-Image
@DevTwitter | <Diego Jr/>
1❤30🔥13🍌6👍2
اگر توسعه دهندهی تازه کار php هستید، نرمافزار xampp و wamp بدترین برنامه برای توسعه هستند
اگر با لاراول کار میکنید من بهتون Laravel Herd رو پیشنهاد میکنم که هم نصب سادهای داره و هم سرعت عالی برای اجرای برنامههای لاراولی
در غیر اینصورت Laragon رو نصب کنید و از توسعه برنامههای php لذت ببرید
@DevTwitter | <sina khaghani/>
اگر با لاراول کار میکنید من بهتون Laravel Herd رو پیشنهاد میکنم که هم نصب سادهای داره و هم سرعت عالی برای اجرای برنامههای لاراولی
در غیر اینصورت Laragon رو نصب کنید و از توسعه برنامههای php لذت ببرید
@DevTwitter | <sina khaghani/>
1👍52👎9🍌5❤3
اگه میخوای برای کارت یا استفاده شخصی،
تو یه زمینه خاص از AI استفاده کنی
ولی نمیدونی دقیقاً کدوم مدل به دردت میخوره
میتونی از http://LMArena.ai کمک بگیری.
مدلها رو کنار هم میبینی،عملکردشون رو مقایسه میکنی،نقطات قوت وضعفشون رو میبینی
یاحتی رایگان و برای استفاده دم دستی هم میشه ازش استفاده کرد
@DevTwitter | <POURYA/>
تو یه زمینه خاص از AI استفاده کنی
ولی نمیدونی دقیقاً کدوم مدل به دردت میخوره
میتونی از http://LMArena.ai کمک بگیری.
مدلها رو کنار هم میبینی،عملکردشون رو مقایسه میکنی،نقطات قوت وضعفشون رو میبینی
یاحتی رایگان و برای استفاده دم دستی هم میشه ازش استفاده کرد
@DevTwitter | <POURYA/>
❤17👍4👎3🔥1
در طول هفته گذشته فرصتی شد تا یک دستی به سر و گوش پلاگین IconLab بکشم و یک ویژگی جدید هم بهش اضافه کنم. امیدوارم خوشتون بیاد و ازش تو پروژه هاتون استفاده کنید. اگر نظری در مورد بهبودش دارید حتما تو لینکدین یا ایمیل بهم پیام بدید تا در موردش گپ بزنیم.
لینک IconLab در کامیونیتی فیگما
https://www.figma.com/community/plugin/1470150361236399232/iconlab-tools-for-managing-icons
چیزهایی که بهش اضافه شده:
- با ویژگی Rename می تونید براحتی یک پیش نمایشی از ایکونهاتون ببینید و اسمشون رو عوض کنید.
ویژگی Flatten چی هست؟
در UI ساختمان ایکون بسیار مهمه و حتما باید ساختار درست و استانداردی داشته باشه. ویژگی Flatten در این پلاگین کمک می کنه:
- همه گروهها و فریمهای اضافی داخل ایکون رو پاک کنید.
- همه لایههای Stroke رو به Fill تبدیل کنید.
- لایههای Mask و Placeholder رو حذف کنید.
- اسم و رنگ لایه اصلی همه آیکون رو یکسان کنید.
- نقاط یا همون Node های اضافی ایکون رو حذف کنید.
همه این کارها فقط با یک کلیک انجام میشه و جالبش اینجاست که شما می تونید همه این کارها رو در عرض ۲-۳ ثانیه روی صدها آیکون همزمان انجام بدید!
اگر دوست داشتید و استفاده کردید، ممنون میشم با لایک و کامنت تو کامیونیتی فیگما حمایت کنید
@DevTwitter | <Vahid Mehrad/>
لینک IconLab در کامیونیتی فیگما
https://www.figma.com/community/plugin/1470150361236399232/iconlab-tools-for-managing-icons
چیزهایی که بهش اضافه شده:
- با ویژگی Rename می تونید براحتی یک پیش نمایشی از ایکونهاتون ببینید و اسمشون رو عوض کنید.
ویژگی Flatten چی هست؟
در UI ساختمان ایکون بسیار مهمه و حتما باید ساختار درست و استانداردی داشته باشه. ویژگی Flatten در این پلاگین کمک می کنه:
- همه گروهها و فریمهای اضافی داخل ایکون رو پاک کنید.
- همه لایههای Stroke رو به Fill تبدیل کنید.
- لایههای Mask و Placeholder رو حذف کنید.
- اسم و رنگ لایه اصلی همه آیکون رو یکسان کنید.
- نقاط یا همون Node های اضافی ایکون رو حذف کنید.
همه این کارها فقط با یک کلیک انجام میشه و جالبش اینجاست که شما می تونید همه این کارها رو در عرض ۲-۳ ثانیه روی صدها آیکون همزمان انجام بدید!
اگر دوست داشتید و استفاده کردید، ممنون میشم با لایک و کامنت تو کامیونیتی فیگما حمایت کنید
@DevTwitter | <Vahid Mehrad/>
❤11👍2🔥1
تایم اوت بالا در سرویسها: مشکل از کیه؟ API Manager یا Backend؟ ️
یکی از رایجترین سؤالها در تیمهای یکپارچهسازی اینه که:
«وقتی زمان پاسخدهی یک سرویس زیاده، من که API Manager یا ESB هستم Timeout رو روی چند ثانیه تنظیم کنم؟»
ظاهرش سادهست؛ ولی پشتش یک نکته مهم وجود داره:
تایم اوت رو ESB یا API Manager تعیین نمیکنه؛ معماری سیستم تعیین میکنه.
خیلی وقتها Timeout بالا فقط مشکل "طولانی بودن پردازش" نیست، بلکه نشونه یک مشکل بزرگتره.
چرا نباید Timeout رو زیاد کنیم؟
اگر Backend کند باشه، طولانیکردن Timeout فقط مشکل رو پنهان میکنه.
مثلاً Lag در گیتوی باعث میشه کانکشنها قفل بشن و Load کل سیستم بالا بره.
صف درخواستها روی گیتوی ساخته میشه و کل سیستم ناپایدار میشه.
چه کارهایی باید انجام بشه؟
1- ریشه مشکل کندی سرویس رو پیدا کن
کوئریهای سنگین دیتابیس
تعداد I/O زیاد
سرویسهای زنجیرهای کند
یا Memory leak
یا Thread pool ناکافی
تا وقتی اینها درست نشه، هیچ تایم اوتی مساعد نخواهد بود.
2- تایماوت (Timeout) باید متناسب با نوع سرویس باشه
سرویسهای synchronous مثل اطلاعات مشتری: ۳–۱۰ ثانیه
سرویسهای پردازش سنگین: اصلاً synchronous نباید باشن
3- کارهای سنگین رو asynchronous کن
برای عملیات طولانی از:
Kafka
Redis queue
Celery
SQS
Internal event bus
استفاده کن و نتیجه رو بعداً تحویل بده.
4- بخش API Manager محل پردازش نیست
بخش ESB/WSO2/APIM فقط باید:
درخواست رو مدیریت کنه
امنیت رو برقرار کنه
نرخ و دسترسی رو کنترل کنه
نه اینکه ۳۰ ثانیه منتظر بمونه یک Backend تموم بشه!
5- تایماوتهای چندگانه تنظیم کن
Gateway timeout
Backend timeout
Load balancer timeout
Client timeout
اینها باید یکپارچه و هماهنگ باشن.
نتیجه
اگر یک سرویس کند است، بهترین راهحل "زیاد کردن Timeout" نیست.
راهحل طراحی درست و انتقال پردازشهای سنگین به async است.
تایماوت باید حداقلی، منطقی و قابل پیشبینی باشد، نه پنهانکننده مشکل.
@DevTwitter | <Mobin Mokhtarzadeh/>
یکی از رایجترین سؤالها در تیمهای یکپارچهسازی اینه که:
«وقتی زمان پاسخدهی یک سرویس زیاده، من که API Manager یا ESB هستم Timeout رو روی چند ثانیه تنظیم کنم؟»
ظاهرش سادهست؛ ولی پشتش یک نکته مهم وجود داره:
تایم اوت رو ESB یا API Manager تعیین نمیکنه؛ معماری سیستم تعیین میکنه.
خیلی وقتها Timeout بالا فقط مشکل "طولانی بودن پردازش" نیست، بلکه نشونه یک مشکل بزرگتره.
چرا نباید Timeout رو زیاد کنیم؟
اگر Backend کند باشه، طولانیکردن Timeout فقط مشکل رو پنهان میکنه.
مثلاً Lag در گیتوی باعث میشه کانکشنها قفل بشن و Load کل سیستم بالا بره.
صف درخواستها روی گیتوی ساخته میشه و کل سیستم ناپایدار میشه.
چه کارهایی باید انجام بشه؟
1- ریشه مشکل کندی سرویس رو پیدا کن
کوئریهای سنگین دیتابیس
تعداد I/O زیاد
سرویسهای زنجیرهای کند
یا Memory leak
یا Thread pool ناکافی
تا وقتی اینها درست نشه، هیچ تایم اوتی مساعد نخواهد بود.
2- تایماوت (Timeout) باید متناسب با نوع سرویس باشه
سرویسهای synchronous مثل اطلاعات مشتری: ۳–۱۰ ثانیه
سرویسهای پردازش سنگین: اصلاً synchronous نباید باشن
3- کارهای سنگین رو asynchronous کن
برای عملیات طولانی از:
Kafka
Redis queue
Celery
SQS
Internal event bus
استفاده کن و نتیجه رو بعداً تحویل بده.
4- بخش API Manager محل پردازش نیست
بخش ESB/WSO2/APIM فقط باید:
درخواست رو مدیریت کنه
امنیت رو برقرار کنه
نرخ و دسترسی رو کنترل کنه
نه اینکه ۳۰ ثانیه منتظر بمونه یک Backend تموم بشه!
5- تایماوتهای چندگانه تنظیم کن
Gateway timeout
Backend timeout
Load balancer timeout
Client timeout
اینها باید یکپارچه و هماهنگ باشن.
نتیجه
اگر یک سرویس کند است، بهترین راهحل "زیاد کردن Timeout" نیست.
راهحل طراحی درست و انتقال پردازشهای سنگین به async است.
تایماوت باید حداقلی، منطقی و قابل پیشبینی باشد، نه پنهانکننده مشکل.
@DevTwitter | <Mobin Mokhtarzadeh/>
❤16👍7🔥1
اخیراً فرصتی دست داد تا یک سرویس کوتاهکننده URL نسبتا خوب و scalable بسازم – چیزی که نه تنها لینکهای طولانی رو به کدهای کوتاه و کارآمد تبدیل میکنه، بلکه با تمرکز روی performance و امنیت، برای محیطهای production-ready طراحی شده. از FastAPI برای API layer استفاده کردم، PostgreSQL رو به عنوان primary store، و Redis برای caching سریع lookups.
چالشهای جالبی تو پیادهسازی داشت: مثلاً مدیریت collision-free short codes با Base62 encoding (تا ۹۱۶ میلیون unique URL)، و کاهش latency redirectها به زیر ۵ میلیثانیه با cache hits. همچنین، SSRF protection و rate limiting رو اضافه کردم تا از حملات احتمالی جلوگیری بشه. آمارگیری کلیکها هم با tracking timestamps، insights خوبی برای analytics میده.
سرویس کاملاً Dockerized هست و با یک docker-compose up، آماده اجراست. اگر به backend، optimization یا scaling علاقهمندید، کد رو چک کنین. خوشحال میشم feedbackهای فنیتون رو بشنوم، مثلاً در مورد horizontal scaling یا integration با CDN.
https://github.com/sajadfallahdoost/URL-shortener
@DevTwitter | <sajad fallahdoost/>
چالشهای جالبی تو پیادهسازی داشت: مثلاً مدیریت collision-free short codes با Base62 encoding (تا ۹۱۶ میلیون unique URL)، و کاهش latency redirectها به زیر ۵ میلیثانیه با cache hits. همچنین، SSRF protection و rate limiting رو اضافه کردم تا از حملات احتمالی جلوگیری بشه. آمارگیری کلیکها هم با tracking timestamps، insights خوبی برای analytics میده.
سرویس کاملاً Dockerized هست و با یک docker-compose up، آماده اجراست. اگر به backend، optimization یا scaling علاقهمندید، کد رو چک کنین. خوشحال میشم feedbackهای فنیتون رو بشنوم، مثلاً در مورد horizontal scaling یا integration با CDN.
https://github.com/sajadfallahdoost/URL-shortener
@DevTwitter | <sajad fallahdoost/>
❤28🍌14👍2🔥1