#کدبوک
یک راهنمای کاربردی برای درک و پیادهسازی الگوریتمهای مهم در برنامهنویسی:
- پوشش الگوریتمهای جستجو، مرتبسازی، گراف و بهینهسازی
- توضیح مفاهیم با مثالهای عملی و ساده
- کمک به بهبود مهارت حل مسئله و طراحی ساختارهای کارآمد
- مناسب برای برنامهنویسهایی که میخوان پایه الگوریتمی خودشون رو تقویت کنن
* فایل PDF این کتاب رو میتونید از کانال DevBooks که لینکش توی بیو هست دانلود کنید.
@DevTwitter
یک راهنمای کاربردی برای درک و پیادهسازی الگوریتمهای مهم در برنامهنویسی:
- پوشش الگوریتمهای جستجو، مرتبسازی، گراف و بهینهسازی
- توضیح مفاهیم با مثالهای عملی و ساده
- کمک به بهبود مهارت حل مسئله و طراحی ساختارهای کارآمد
- مناسب برای برنامهنویسهایی که میخوان پایه الگوریتمی خودشون رو تقویت کنن
* فایل PDF این کتاب رو میتونید از کانال DevBooks که لینکش توی بیو هست دانلود کنید.
@DevTwitter
🔥12❤6👍1👎1
This media is not supported in your browser
VIEW IN TELEGRAM
اگه با این AI coding assistant ها کد میزنید یا اینکه به صورت vibe coding اپ میسازید اینکه چطور دیزاین را هم وارد مساله کنید خیلی مهمه. یک اصطلاح جدید داره بوجود میاد به اسم "vibe designing". این بلاگ خیلی قشنگ توضیح میده و اینکه موقع vibe coding چطور یک اپ با طراحی خوب درست کنید. حتما بخونید. ویدیو هم تو یوتیوب داره:
https://designwithai.substack.com/p/vibe-designing-with-ai
YT: https://youtube.com/watch?v=QgvQbcPmioE
@DevTwitter | <Mehdi Allahyari/>
https://designwithai.substack.com/p/vibe-designing-with-ai
YT: https://youtube.com/watch?v=QgvQbcPmioE
@DevTwitter | <Mehdi Allahyari/>
❤17🍌2👍1🔥1
چرا Docker و RHEL از هم فاصله گرفتند؟
ردهت از زمان انتشار RHEL 8 پشتیبانی رسمی Docker Engine را متوقف کرد. دلیل اصلی این بود که معماری Docker با مدل امنیتی RHEL همراستا نبود؛ Docker یک daemon سطحبالا دارد که بهصورت root اجرا میشود و یک نقطهی شکست و ریسک امنیتی مهم ایجاد میکند. Red Hat برای محیطهای Enterprise چیزی میخواست که هم بدون daemon باشد، هم با SELinux و استانداردهای سختگیرانه امنیتی آن کاملاً سازگار بماند.
به همین دلیل، Red Hat به جای Docker از مجموعه ابزارهای Podman، Buildah و Skopeo استفاده کرد. این ابزارها کاملاً متنبازند، با استانداردهای OCI هماهنگی کامل دارند و در بسیاری از سناریوها میتوانند جای Docker را بدون تغییرات جدی بگیرند. Podman حتی قادر است همان دستورات Docker را اجرا کند. مهمتر اینکه بدون نیاز به daemon و با امکان اجرای rootless کار میکند، که از نظر امنیت و سازگاری با سیاستهای RHEL یک مزیت بزرگ محسوب میشود.
در همین زمان، Kubernetes نیز مسیر مشابهی رفت: dockershim را کنار گذاشت و بهصورت رسمی از containerd و CRI-O پشتیبانی کرد. ردهت که خود توسعهدهنده CRI-O و OpenShift است، طبیعی بود که با جهت K8s همسو شود، نه با Docker Engine.
داکر Inc هم در سالهای اخیر بیشتر روی Docker Desktop، مدل لایسنس جدید و سرویسهای Cloud تمرکز کرد—در حالی که Red Hat به دنبال یک زنجیره تأمین کاملاً متنباز و پایدار بود. این تفاوت فلسفه باعث شد فاصله این دو اکوسیستم بیشتر شود.
نتیجه؟ Docker در دنیای Ubuntu و Dev-friendly هنوز پادشاه سادگی است، اما در اکوسیستم RHEL (و توزیعهای سازگار مثل Rocky/AlmaLinux) Podman استاندارد اصلی و گزینهٔ پایدارتر و امنتر محسوب میشود.
@DevTwitter | <Babak uk/>
ردهت از زمان انتشار RHEL 8 پشتیبانی رسمی Docker Engine را متوقف کرد. دلیل اصلی این بود که معماری Docker با مدل امنیتی RHEL همراستا نبود؛ Docker یک daemon سطحبالا دارد که بهصورت root اجرا میشود و یک نقطهی شکست و ریسک امنیتی مهم ایجاد میکند. Red Hat برای محیطهای Enterprise چیزی میخواست که هم بدون daemon باشد، هم با SELinux و استانداردهای سختگیرانه امنیتی آن کاملاً سازگار بماند.
به همین دلیل، Red Hat به جای Docker از مجموعه ابزارهای Podman، Buildah و Skopeo استفاده کرد. این ابزارها کاملاً متنبازند، با استانداردهای OCI هماهنگی کامل دارند و در بسیاری از سناریوها میتوانند جای Docker را بدون تغییرات جدی بگیرند. Podman حتی قادر است همان دستورات Docker را اجرا کند. مهمتر اینکه بدون نیاز به daemon و با امکان اجرای rootless کار میکند، که از نظر امنیت و سازگاری با سیاستهای RHEL یک مزیت بزرگ محسوب میشود.
در همین زمان، Kubernetes نیز مسیر مشابهی رفت: dockershim را کنار گذاشت و بهصورت رسمی از containerd و CRI-O پشتیبانی کرد. ردهت که خود توسعهدهنده CRI-O و OpenShift است، طبیعی بود که با جهت K8s همسو شود، نه با Docker Engine.
داکر Inc هم در سالهای اخیر بیشتر روی Docker Desktop، مدل لایسنس جدید و سرویسهای Cloud تمرکز کرد—در حالی که Red Hat به دنبال یک زنجیره تأمین کاملاً متنباز و پایدار بود. این تفاوت فلسفه باعث شد فاصله این دو اکوسیستم بیشتر شود.
نتیجه؟ Docker در دنیای Ubuntu و Dev-friendly هنوز پادشاه سادگی است، اما در اکوسیستم RHEL (و توزیعهای سازگار مثل Rocky/AlmaLinux) Podman استاندارد اصلی و گزینهٔ پایدارتر و امنتر محسوب میشود.
@DevTwitter | <Babak uk/>
👍36❤6🔥4
#کدبوک
مجموعهای از نکات کوتاه و کاربردی برای بهتر شدن در برنامهنویسی و کار حرفهای:
- توصیههایی درباره طراحی، نگهداری و کیفیت کد
- نکات مهم درباره همکاری تیمی، تست و مستندسازی
- دیدگاههایی از برنامهنویسهای باتجربه در حوزههای مختلف
- مناسب برای هر توسعهدهندهای که میخواد عادتها و نگرش حرفهایتری پیدا کنه
* فایل PDF این کتاب رو میتونید از کانال DevBooks که لینکش توی بیو هست دانلود کنید.
@DevTwitter
مجموعهای از نکات کوتاه و کاربردی برای بهتر شدن در برنامهنویسی و کار حرفهای:
- توصیههایی درباره طراحی، نگهداری و کیفیت کد
- نکات مهم درباره همکاری تیمی، تست و مستندسازی
- دیدگاههایی از برنامهنویسهای باتجربه در حوزههای مختلف
- مناسب برای هر توسعهدهندهای که میخواد عادتها و نگرش حرفهایتری پیدا کنه
* فایل PDF این کتاب رو میتونید از کانال DevBooks که لینکش توی بیو هست دانلود کنید.
@DevTwitter
❤17👎3🔥1
یک بلاگ جالب خوندم با موضوع "به ماشین یاد بده چطور فکر کنه!". حتما بخونیدش ولی چکیده اش را اینجا مینویسم:
آیندهی کار دیگه «حل مسئله» نیست، بلکه «حلِ روشِ حل مسئله» است!
۱/ تصور کنید تو یه مسابقه دیتا ساینس (Kaggle) شرکت میکنید، حتی یک خط کد برای فیچر انجینیرینگ یا تیون کردن مدل نمینویسید، اما جزو ۲۰٪ برتر میشید. جادو نیست؛ نویسنده این مقاله اسمش رو گذاشته «متا-کدینگ» (Meta-Coding). داستان چیه؟
۲/ روال سنتی کار ما اینطوریه: دیتا رو میگیریم، تمیز میکنیم، مدل میسازیم، ارور میده، دیباگ میکنیم و دوباره از اول.
اما نویسنده میگه بیاید یه پله برید بالاتر. به جای اینکه خودتون مسئله رو حل کنید، یه سیستم بسازید که بدونه چطور باید مسئله رو حل کنه.
۳/ توی متا-کدینگ، وقتی سیستمتون خرابکاری میکنه یا باگ میده، شما نمیرید کد رو پچ کنید (مثلاً یه if بذارید که کرش نکنه).
شما از خودتون میپرسید: «چی توی درک و فهمِ سیستم کم بود که باعث این اشتباه شد؟»
شما کد رو دیباگ نمیکنید، دارید «فهم» (Understanding) سیستم رو دیباگ میکنید.
۴/ نویسنده یه سیستم ساخته به اسم ML Planner. این سیستم کدهای پایتون نداره که بگه "فلان ستون رو اینجوری نرمال کن". بلکه یه سری داکیومنت متنی داره (لایه دانش) که به ایجنتهای هوش مصنوعی (مثل GPT یا Claude) یاد میده یه متخصص چطور فکر میکنه.
مثلاً: "کی باید از Target Encoding استفاده کنی؟" یا "چطور حواست به هزینه سرورهای GPU باشه؟"
۵/ یه مثال شاهکار دیگه تو مقاله هست: شرکت حقوقی CaseText.
اینا نیومدن یه موتور جستجوی حقوقی بسازن. اومدن «نحوه فکر کردن یه وکیل خبره» رو مهندسی معکوس کردن.
هر مرحله از فکر کردن وکیل (فهم سوال، ریسرچ، یادداشتبرداری، تطبیق قوانین) شد یه پرامپت. نتیجه؟ شرکتشون رو ۶۵۰ میلیون دلار فروختن! چون اونا «دانش» رو کد کرده بودن، نه فقط نرمافزار رو.
۶/ ما داریم وارد دنیایی میشیم که سلسلهمراتب ارزش داره تغییر میکنه:
سطح ۱: انجام دادن کار (ارزش خطی: ساعتی پول میگیرید).
سطح ۲: ساختن سیستمی که کار رو انجام بده.
سطح ۳: بهبود روشی که سیستمها رو میسازید (ارزش تصاعدی).
۷/ حالا شما چطور شروع کنید؟
هر وقت دارید یه کار تکراری انجام میدید (تو برنامهنویسی، نوشتن، مارکتینگ یا هرچی)، یه لحظه صبر کنید.
از خودتون بپرسید: «اگه بهترین متخصص این حوزه بینهایت زمان و ۱۰۰۰ تا دستیار هوش مصنوعی داشت، چطور این مسئله رو حل میکرد؟»
۸/ اون پروسه فکری، اون شهود (Intuition) و اون قلقهای ریز رو بنویسید.
این داکیومنت میشه اولین قدم شما برای متا-کدینگ.
به جای اینکه خودتون مجری باشید، بشید «معلمِ ایجنتها». وقتی ایجنت گیر کرد، بهش ماهی ندید، ماهیگیری یاد بدید (داکیومنت رو آپدیت کنید).
۹/ خلاصه اینکه: آینده متعلق به کسایی نیست که فقط کد میزنن یا متن مینویسن. آینده مال کساییه که میتونن «شهود» و تجربه نانوشتهشون رو تبدیل به دستورالعملهای شفاف برای ماشینها بکنن.
شما دارید از نردبان بالا میرید تا به جای حل مسئله، «حلکننده» بسازید.
لینک مقاله اصلی:
https://yewjin.substack.com/p/the-future-is-solving-problem-solving
@DevTwitter | <Mehdi Allahyari/>
آیندهی کار دیگه «حل مسئله» نیست، بلکه «حلِ روشِ حل مسئله» است!
۱/ تصور کنید تو یه مسابقه دیتا ساینس (Kaggle) شرکت میکنید، حتی یک خط کد برای فیچر انجینیرینگ یا تیون کردن مدل نمینویسید، اما جزو ۲۰٪ برتر میشید. جادو نیست؛ نویسنده این مقاله اسمش رو گذاشته «متا-کدینگ» (Meta-Coding). داستان چیه؟
۲/ روال سنتی کار ما اینطوریه: دیتا رو میگیریم، تمیز میکنیم، مدل میسازیم، ارور میده، دیباگ میکنیم و دوباره از اول.
اما نویسنده میگه بیاید یه پله برید بالاتر. به جای اینکه خودتون مسئله رو حل کنید، یه سیستم بسازید که بدونه چطور باید مسئله رو حل کنه.
۳/ توی متا-کدینگ، وقتی سیستمتون خرابکاری میکنه یا باگ میده، شما نمیرید کد رو پچ کنید (مثلاً یه if بذارید که کرش نکنه).
شما از خودتون میپرسید: «چی توی درک و فهمِ سیستم کم بود که باعث این اشتباه شد؟»
شما کد رو دیباگ نمیکنید، دارید «فهم» (Understanding) سیستم رو دیباگ میکنید.
۴/ نویسنده یه سیستم ساخته به اسم ML Planner. این سیستم کدهای پایتون نداره که بگه "فلان ستون رو اینجوری نرمال کن". بلکه یه سری داکیومنت متنی داره (لایه دانش) که به ایجنتهای هوش مصنوعی (مثل GPT یا Claude) یاد میده یه متخصص چطور فکر میکنه.
مثلاً: "کی باید از Target Encoding استفاده کنی؟" یا "چطور حواست به هزینه سرورهای GPU باشه؟"
۵/ یه مثال شاهکار دیگه تو مقاله هست: شرکت حقوقی CaseText.
اینا نیومدن یه موتور جستجوی حقوقی بسازن. اومدن «نحوه فکر کردن یه وکیل خبره» رو مهندسی معکوس کردن.
هر مرحله از فکر کردن وکیل (فهم سوال، ریسرچ، یادداشتبرداری، تطبیق قوانین) شد یه پرامپت. نتیجه؟ شرکتشون رو ۶۵۰ میلیون دلار فروختن! چون اونا «دانش» رو کد کرده بودن، نه فقط نرمافزار رو.
۶/ ما داریم وارد دنیایی میشیم که سلسلهمراتب ارزش داره تغییر میکنه:
سطح ۱: انجام دادن کار (ارزش خطی: ساعتی پول میگیرید).
سطح ۲: ساختن سیستمی که کار رو انجام بده.
سطح ۳: بهبود روشی که سیستمها رو میسازید (ارزش تصاعدی).
۷/ حالا شما چطور شروع کنید؟
هر وقت دارید یه کار تکراری انجام میدید (تو برنامهنویسی، نوشتن، مارکتینگ یا هرچی)، یه لحظه صبر کنید.
از خودتون بپرسید: «اگه بهترین متخصص این حوزه بینهایت زمان و ۱۰۰۰ تا دستیار هوش مصنوعی داشت، چطور این مسئله رو حل میکرد؟»
۸/ اون پروسه فکری، اون شهود (Intuition) و اون قلقهای ریز رو بنویسید.
این داکیومنت میشه اولین قدم شما برای متا-کدینگ.
به جای اینکه خودتون مجری باشید، بشید «معلمِ ایجنتها». وقتی ایجنت گیر کرد، بهش ماهی ندید، ماهیگیری یاد بدید (داکیومنت رو آپدیت کنید).
۹/ خلاصه اینکه: آینده متعلق به کسایی نیست که فقط کد میزنن یا متن مینویسن. آینده مال کساییه که میتونن «شهود» و تجربه نانوشتهشون رو تبدیل به دستورالعملهای شفاف برای ماشینها بکنن.
شما دارید از نردبان بالا میرید تا به جای حل مسئله، «حلکننده» بسازید.
لینک مقاله اصلی:
https://yewjin.substack.com/p/the-future-is-solving-problem-solving
@DevTwitter | <Mehdi Allahyari/>
❤53👍7🔥2
Media is too big
VIEW IN TELEGRAM
پردازش ۴۰ میلیارد رکورد در روز — معماری یک سیستم مقیاسپذیر!
خیلیها فکر میکنن پردازش دهها میلیارد رکورد در روز فقط از پس غولهای جهانی مثل Meta یا Netflix برمیاد — اما من یک معماری عملیاتی ساختم که روزانه بالغ بر ۴۰ میلیارد رکورد (معادل تقریبا ۵۰۰ هزار رکورد بر ثانیه) رو از Kafka مصرف و بهصورت بهینه در ClickHouse ذخیره میکنه.
چالش اصلی
بار نامتعادل روی کلاستر توزیعشده شلوغ با ۲۰ نود و ۵۲ پارتیشن و عدم تفکیک داده
نیاز به پردازش کمتأخیر
حفظ Consistency در حجم عظیم داده
راهحل معماری
مصرفکنندههای موازی با Unbounded Channel
پردازش کاملاً Stateless برای scale عمودی و افقی
دستهبندی و فشردهسازی در Batchهای ۱,۰۰۰,۰۰۰ رکوردی (قابل کانفیگ)
نوشتن مستقیم در ClickHouse با Insertهای ستونمحور
و Commit offset تنها بعد از نوشتن موفق
جدا کردن مسیر ingest از persist برای افزایش throughput
@DevTwitter | <Amirhossein Maleki/>
خیلیها فکر میکنن پردازش دهها میلیارد رکورد در روز فقط از پس غولهای جهانی مثل Meta یا Netflix برمیاد — اما من یک معماری عملیاتی ساختم که روزانه بالغ بر ۴۰ میلیارد رکورد (معادل تقریبا ۵۰۰ هزار رکورد بر ثانیه) رو از Kafka مصرف و بهصورت بهینه در ClickHouse ذخیره میکنه.
چالش اصلی
بار نامتعادل روی کلاستر توزیعشده شلوغ با ۲۰ نود و ۵۲ پارتیشن و عدم تفکیک داده
نیاز به پردازش کمتأخیر
حفظ Consistency در حجم عظیم داده
راهحل معماری
مصرفکنندههای موازی با Unbounded Channel
پردازش کاملاً Stateless برای scale عمودی و افقی
دستهبندی و فشردهسازی در Batchهای ۱,۰۰۰,۰۰۰ رکوردی (قابل کانفیگ)
نوشتن مستقیم در ClickHouse با Insertهای ستونمحور
و Commit offset تنها بعد از نوشتن موفق
جدا کردن مسیر ingest از persist برای افزایش throughput
@DevTwitter | <Amirhossein Maleki/>
❤25🍌8🔥5👎2
وردپرس 6.9 منتشر شد
این نسخه به افتخار هنرمند سرشناس پیانو سبک جاز، Gene Harris نام گذاری شده که شاهد تحولات قابل توجهی می باشد. بیش از ۷۰ بهبود در دسترسپذیری و Abilities API برای تعاملات یکپارچه در PHP، REST و زمینههای مبتنی بر AI بخشی از ویژگی های این نسخه است.
@DevTwitter | <Alireza Naji/>
این نسخه به افتخار هنرمند سرشناس پیانو سبک جاز، Gene Harris نام گذاری شده که شاهد تحولات قابل توجهی می باشد. بیش از ۷۰ بهبود در دسترسپذیری و Abilities API برای تعاملات یکپارچه در PHP، REST و زمینههای مبتنی بر AI بخشی از ویژگی های این نسخه است.
@DevTwitter | <Alireza Naji/>
🍌23❤22👍1👎1
اخیرا میخواستم German String رو پیاده سازی کنم اما دیدم واسه Refcount بودن استرینگ و substr گرفتن بدون hardcopy استفاده های بیشتری دارم.
متاسفانه هنوز string literal بدون allocation ساپورت نمیکنه و هنوز ایده ای به ذهنم نرسیده چطور تو 128بیت درستش کنم.
https://github.com/hexorer/libtoypp/blob/main/include/toypp/immutable_string.hpp
@DevTwitter | <Mohsen M./>
متاسفانه هنوز string literal بدون allocation ساپورت نمیکنه و هنوز ایده ای به ذهنم نرسیده چطور تو 128بیت درستش کنم.
https://github.com/hexorer/libtoypp/blob/main/include/toypp/immutable_string.hpp
@DevTwitter | <Mohsen M./>
👍7🍌7❤1🔥1
وقتی افزونهها کمکم تبدیل میشن به همتیمیهای واقعی…
امروز Cline رو روی VS Code تست کردم و رسماً فهمیدم دوران «تنهایی در کدنویسی» داره تموم میشه.
این موجود فضاییِ کوچک توی ادیتورم نهتنها کد میخونه، بلکه ایراد میگیره، پیشنهاد میده، فایل میسازه، پاک میکنه، حتی ترمینال رو هم دستکاری میکنه.
یک جورهایی انگار داری با یه دولوپر دیگه pair programming میکنی… فقط بدون غر زدن!
دنیای برنامهنویسی داره یه لایه جدید پیدا میکنه:
کد کمتر، فکر بیشتر.
اگه هنوز امتحانش نکردی… چند قدم مونده تا اینکه واقعاً حس کنی IDEت بامرامتر از خیلی از همکاراست.
@DevTwitter | <Amin Hosseini/>
امروز Cline رو روی VS Code تست کردم و رسماً فهمیدم دوران «تنهایی در کدنویسی» داره تموم میشه.
این موجود فضاییِ کوچک توی ادیتورم نهتنها کد میخونه، بلکه ایراد میگیره، پیشنهاد میده، فایل میسازه، پاک میکنه، حتی ترمینال رو هم دستکاری میکنه.
یک جورهایی انگار داری با یه دولوپر دیگه pair programming میکنی… فقط بدون غر زدن!
دنیای برنامهنویسی داره یه لایه جدید پیدا میکنه:
کد کمتر، فکر بیشتر.
اگه هنوز امتحانش نکردی… چند قدم مونده تا اینکه واقعاً حس کنی IDEت بامرامتر از خیلی از همکاراست.
@DevTwitter | <Amin Hosseini/>
👎33👍17❤8🍌5
اپ فال حافظ من از یک نیاز خیلی ساده شروع شد؛ همیشه وقتی دور هم جمع میشدیم و فال میگرفتیم، دوست داشتم یک اپ تمیز و کاملاً فارسی داشته باشم که هم فال تصادفی بده، هم تعبیرش رو قشنگ و خوانا نشان بده برای همین رفتم سراغ Flutter و این پروژه رو ساختم تا روی اندروید، ویندوز و بقیه پلتفرمها هم قابل اجرا باشه و هرکس خواست راحت بتونه ازش استفاده کنه یا توی گیتهاب کمک کنه
اسم پروژه only_faleh_hafez هست و داخلش میتونی با یک کلیک فال تصادفی از دیوان حافظ بگیری، تعبیر و توضیح اون فال رو بخونی و اگر دنبال شعر خاصی هستی، مستقیم داخل اشعار جستوجو کنی رابط کاربری کامل فارسی و راستبهچپ طراحی شده تا حس یک اپ بومی و ساده رو بده، نه یک چیز ترجمهشدهی عجیب؛ هدفم این بوده که هم برای کاربر معمولی راحت باشه، هم برای دولوپرها اوپنسورس و قابل توسعه
لینک ریپو و توضیحات کاملتر پروژه:
https://github.com/MMDREZA7/only_faleh_hafez
@DevTwitter | <Ethan Heida/>
اسم پروژه only_faleh_hafez هست و داخلش میتونی با یک کلیک فال تصادفی از دیوان حافظ بگیری، تعبیر و توضیح اون فال رو بخونی و اگر دنبال شعر خاصی هستی، مستقیم داخل اشعار جستوجو کنی رابط کاربری کامل فارسی و راستبهچپ طراحی شده تا حس یک اپ بومی و ساده رو بده، نه یک چیز ترجمهشدهی عجیب؛ هدفم این بوده که هم برای کاربر معمولی راحت باشه، هم برای دولوپرها اوپنسورس و قابل توسعه
لینک ریپو و توضیحات کاملتر پروژه:
https://github.com/MMDREZA7/only_faleh_hafez
@DevTwitter | <Ethan Heida/>
🍌29❤19👍6👎2
چرا pnpm, بهتر از npm عمل میکنه
چند وقت پیش برای اولین بار که از pnpm استفاده میکردم (با سرعت نت همیشگی)، فر خوردم از سرعت نصب پکیج و این سوال برام پیش اومد که چرا؟؟؟
حالا ماجرا چیه؟
خب، npm همون مدیر بستهٔ کلاسیکِ Node هستش. ساده، همهکاره، ولی هر پروژه یه کپی از بستهها توی node_modules نگه میداره — فضای دیسک زیاد و بعضاً نصبهای کند. جدیدترها هم بهتر شدن ولی هنوز محدودیت دارن ولی pnpm, یک سبک دیگه داره. بستهها رو توی یک مخزن مرکزی (content-addressable store) ذخیره میکنه و داخل پروژه فقط لینک (hardlink/symlink) میسازه. یعنی: کمتر تکرار، نصب سریعتر، و استفادهٔ خیلی بهینه از دیسک یعنی یه بار نصب و ذخیره میکنه توی سیستم مرکزی خودش و یه لینک میزاره برای استفاده های بعدی.
خب حالا مزیت هاش چیه؟
1. سرعتِ نصب بیشتر — چون فایلهاو دوباره دانلود نمیکنه، وقتتو نمیسوزونه.
2. صرفهجویی در فضا — یک بسته فقط یکبار ذخیره میشه، نه هزار بار توی هر پروژه.
3. سختگیری روی وابستگیها = باگ کمتر — pnpm ساختار غیرفلت node_modules داره؛ یعنی اگر پکیجی بهطور مستقیم به یه بسته نیاز داره ولی اون رو در package.json اعلام نکردی، خطا میده — خیلی وقتا نجاتدهندهست.
4. حمایت بهتر از monorepo/Workspaces — تو تیم و پروژههای چندپکیجهای خیلی راحتتر کار میکنه.
سازگاری با اکوسیستم npm — از رجیستری npm استفاده میکنه، اسکریپتها و package.json تغییر زیادی نیاز ندارن. (این خیلی خفنه )
اگه فقط یکی دو تا پروژه کوچیک داری و با npm راحتی — همون بمونه. ولی اگه میخوای سرعت بیاد بالا، فضا کمتر مصرف بشه یا پروژهت چندپکیجهای/تیمی باشه، pnpm واقعاً بهت حال میده.
@DevTwitter | <Mohammad Ghiasi/>
چند وقت پیش برای اولین بار که از pnpm استفاده میکردم (با سرعت نت همیشگی)، فر خوردم از سرعت نصب پکیج و این سوال برام پیش اومد که چرا؟؟؟
حالا ماجرا چیه؟
خب، npm همون مدیر بستهٔ کلاسیکِ Node هستش. ساده، همهکاره، ولی هر پروژه یه کپی از بستهها توی node_modules نگه میداره — فضای دیسک زیاد و بعضاً نصبهای کند. جدیدترها هم بهتر شدن ولی هنوز محدودیت دارن ولی pnpm, یک سبک دیگه داره. بستهها رو توی یک مخزن مرکزی (content-addressable store) ذخیره میکنه و داخل پروژه فقط لینک (hardlink/symlink) میسازه. یعنی: کمتر تکرار، نصب سریعتر، و استفادهٔ خیلی بهینه از دیسک یعنی یه بار نصب و ذخیره میکنه توی سیستم مرکزی خودش و یه لینک میزاره برای استفاده های بعدی.
خب حالا مزیت هاش چیه؟
1. سرعتِ نصب بیشتر — چون فایلهاو دوباره دانلود نمیکنه، وقتتو نمیسوزونه.
2. صرفهجویی در فضا — یک بسته فقط یکبار ذخیره میشه، نه هزار بار توی هر پروژه.
3. سختگیری روی وابستگیها = باگ کمتر — pnpm ساختار غیرفلت node_modules داره؛ یعنی اگر پکیجی بهطور مستقیم به یه بسته نیاز داره ولی اون رو در package.json اعلام نکردی، خطا میده — خیلی وقتا نجاتدهندهست.
4. حمایت بهتر از monorepo/Workspaces — تو تیم و پروژههای چندپکیجهای خیلی راحتتر کار میکنه.
سازگاری با اکوسیستم npm — از رجیستری npm استفاده میکنه، اسکریپتها و package.json تغییر زیادی نیاز ندارن. (این خیلی خفنه )
اگه فقط یکی دو تا پروژه کوچیک داری و با npm راحتی — همون بمونه. ولی اگه میخوای سرعت بیاد بالا، فضا کمتر مصرف بشه یا پروژهت چندپکیجهای/تیمی باشه، pnpm واقعاً بهت حال میده.
@DevTwitter | <Mohammad Ghiasi/>
❤29👍5👎2🔥2
بهترین روشهای طراحی REST API
طراحی REST API به نظر ساده میاد، اما نکات ریز و مهمی داره که باید رعایت کنیم. معمولا اشتباهاتی در طراحی API مرتکب میشیم که شامل این 5 مورده:
1- استفاده از فعل در آدرس URL
آدرس باید فقط «منبع» (اسم) باشه، نه «عمل» (فعل). عمل رو خود متد HTTP مشخص میکنه.
2- استفاده نادرست از متدهای HTTP
متد درست باعث میشه API خودبهخود قابل فهم باشه:
متد GET گرفتن داده
متد POST ساختن منبع جدید
متد PUT جایگزینی کامل یک منبع
متد PATCH ویرایش جزئی یک منبع
متد DELETE حذف منبع
3- برنگردوندن کد وضعیت مناسب
کلاینت نباید مجبور بشه بدنه پاسخ رو پارس کنه تا بفهمه چی شده.
همیشه 200 OK برگردوندن
پاسخ 200 OK برای GET و PUT موفق
پاسخ 201 Created وقتی با POST منبع جدید ساخته شد
پاسخ 204 No Content وقتی با DELETE چیزی حذف شد
پاسخ 404 Not Found وقتی منبع پیدا نشد
400, 401, 403, 429, 500 و … در مواقع لازم
4- نامگذاری ناسازگار
همه جا یک شکل باشه
گاهی /book/123 گاهی /authors
همیشه جمع بساز: /books/123 ، /authors ، /orders
5- فراموش کردن صفحهبندی (Pagination)
برگردوندن همه رکوردها در یک درخواست دروافع فاجعه عملکردیه
برگردوندن ۱۰۰ هزار رکورد یهجا
همیشه صفحهبندی داشته باش:
?page=3&limit=50
@DevTwitter | <Amir Rahimi Nejad/>
طراحی REST API به نظر ساده میاد، اما نکات ریز و مهمی داره که باید رعایت کنیم. معمولا اشتباهاتی در طراحی API مرتکب میشیم که شامل این 5 مورده:
1- استفاده از فعل در آدرس URL
آدرس باید فقط «منبع» (اسم) باشه، نه «عمل» (فعل). عمل رو خود متد HTTP مشخص میکنه.
GET /getAllBooks
POST /createNewBook
GET /books
POST /books
2- استفاده نادرست از متدهای HTTP
متد درست باعث میشه API خودبهخود قابل فهم باشه:
متد GET گرفتن داده
متد POST ساختن منبع جدید
متد PUT جایگزینی کامل یک منبع
متد PATCH ویرایش جزئی یک منبع
متد DELETE حذف منبع
3- برنگردوندن کد وضعیت مناسب
کلاینت نباید مجبور بشه بدنه پاسخ رو پارس کنه تا بفهمه چی شده.
همیشه 200 OK برگردوندن
پاسخ 200 OK برای GET و PUT موفق
پاسخ 201 Created وقتی با POST منبع جدید ساخته شد
پاسخ 204 No Content وقتی با DELETE چیزی حذف شد
پاسخ 404 Not Found وقتی منبع پیدا نشد
400, 401, 403, 429, 500 و … در مواقع لازم
4- نامگذاری ناسازگار
همه جا یک شکل باشه
گاهی /book/123 گاهی /authors
همیشه جمع بساز: /books/123 ، /authors ، /orders
5- فراموش کردن صفحهبندی (Pagination)
برگردوندن همه رکوردها در یک درخواست دروافع فاجعه عملکردیه
برگردوندن ۱۰۰ هزار رکورد یهجا
همیشه صفحهبندی داشته باش:
?page=3&limit=50
@DevTwitter | <Amir Rahimi Nejad/>
👍37❤9🍌6🔥2
پروژه چت بات با Next.js و مدل Groq
سلام دوستان!
مدتی بود دوست داشتم از دید ریکت و نکست دقیقتر بفهمم ارتباط اپهای وب با مدلهای هوش مصنوعی چطور برقرار میشه؛ مخصوصاً بحث Streaming response که تجربهی کاربر رو شبیه ChatGPT میکنه.
برای تمرین، یه چتبات ساده ساختم با:
Next.js (App Router)
AI SDK
Groq API
مدل llama-3.1-8b-instant
نتیجه یه دموی آنلاین سبک و سریع شد که latency خیلی کمی داره
لینک آنلاین:
https://next-chatbot-beta.vercel.app/
لینک ریپازیتوری:
https://github.com/Reza-Rayan/next-chatbot
یادتون باشه موقع استفاده حتما VPN رو روشن کنید.
@DevTwitter | <Reza Hosseinzade/>
سلام دوستان!
مدتی بود دوست داشتم از دید ریکت و نکست دقیقتر بفهمم ارتباط اپهای وب با مدلهای هوش مصنوعی چطور برقرار میشه؛ مخصوصاً بحث Streaming response که تجربهی کاربر رو شبیه ChatGPT میکنه.
برای تمرین، یه چتبات ساده ساختم با:
Next.js (App Router)
AI SDK
Groq API
مدل llama-3.1-8b-instant
نتیجه یه دموی آنلاین سبک و سریع شد که latency خیلی کمی داره
لینک آنلاین:
https://next-chatbot-beta.vercel.app/
لینک ریپازیتوری:
https://github.com/Reza-Rayan/next-chatbot
یادتون باشه موقع استفاده حتما VPN رو روشن کنید.
@DevTwitter | <Reza Hosseinzade/>
❤25🍌18👎4👍1
اگه کارتون به زمانبندی، برنامهریزی یا بهینهسازی گیر کرده… Google OR-Tools میتونه ناجیتون باشه!
یک کتابخونهی متنباز از گوگله که برای حل مسائل سختی مثل:
- زمانبندی شیفتها
- برنامهریزی تولید
- تخصیص منابع
- طراحی مسیرهای بهینه (TSP/VRP)
خیلی عالی جواب میده.
چیزی که جذابش میکنه CP-SAT Solverشه؛ هم سریع کار میکنه هم با مسائل پیچیده راحت کنار میاد.
چرا سراغش برید؟
- وقتی چندتا کار، چندتا محدودیت و چندتا آدم/ماشین دارید و نمیدونید چطور همه رو هماهنگ کنید
- وقتی میخواید بهترین برنامه ممکن رو با کمترین خطا و بیشترین بازده داشته باشید
- وقتی دادهمحور تصمیم میگیرید و دنبال راهحل «بهینه» هستید
رایگانه، با Python خیلی راحت کار میکنه و برای پروژههای واقعی هم کاملاً کاربردیه.
اگر تجربهاش رو داشتید یا سوالی دارید خوشحال میشم گپ بزنیم
اگه خواستید یادش بگیرید این یه منبع خوبه:
https://d-krupke.github.io/cpsat-primer/00_intro.html
ORTools Optimization Scheduling Google Python OperationsResearch
@DevTwitter | <Ali Baghernia/>
یک کتابخونهی متنباز از گوگله که برای حل مسائل سختی مثل:
- زمانبندی شیفتها
- برنامهریزی تولید
- تخصیص منابع
- طراحی مسیرهای بهینه (TSP/VRP)
خیلی عالی جواب میده.
چیزی که جذابش میکنه CP-SAT Solverشه؛ هم سریع کار میکنه هم با مسائل پیچیده راحت کنار میاد.
چرا سراغش برید؟
- وقتی چندتا کار، چندتا محدودیت و چندتا آدم/ماشین دارید و نمیدونید چطور همه رو هماهنگ کنید
- وقتی میخواید بهترین برنامه ممکن رو با کمترین خطا و بیشترین بازده داشته باشید
- وقتی دادهمحور تصمیم میگیرید و دنبال راهحل «بهینه» هستید
رایگانه، با Python خیلی راحت کار میکنه و برای پروژههای واقعی هم کاملاً کاربردیه.
اگر تجربهاش رو داشتید یا سوالی دارید خوشحال میشم گپ بزنیم
اگه خواستید یادش بگیرید این یه منبع خوبه:
https://d-krupke.github.io/cpsat-primer/00_intro.html
ORTools Optimization Scheduling Google Python OperationsResearch
@DevTwitter | <Ali Baghernia/>
🔥16❤5
چطور فشار روی cpu رو محاسبه می کنیم ؟؟
یه مفهومی به اسم load داریم که با دستور uptime و یا مستقیم از
/proc/loadavg
میشه اون رو دید توی لینوکس 3 نوع load رو گزارش میده به ترتیب از چپ در یک دقیقه اخیر، پنج دقیقه اخیر و پانزده دقیقه اخیر
اما این load چیه؟ فرض کنین یه cpu یک هسته ای داریم load اگه صفر باشه یعنی cpu بیکاره و تا عدد 1 میزان کار اون رو نشون میده.
اگه عدد بیشتر از 1 باشه مثلا 1.65 یعنی cpu مقدار 65% از کاراش توی صف هستند و اگه 5.5 باشه یعنی 450% از کار هاش توی صف هستند.
اما کامپیوتر های الان cpu های بیش از یه هسته دارن مثلا برای یه cpu هشت هسته ای اگه load avg برابر 12 باشه 50% کار ها در صف هستن و اگه زیر 8 باشه یعنی هیچ کار در صفی نداره (درواقع load رو باید بر تعداد هسته ها تقسیم کرد)
مثل تصویر میتونین با دستور lscpu اطلاعات cpu خودتون رو بدست بیارین عکس یه cpu چهار هسته ای رو نشون میده که هشتا ترد داره (از دید کامپیوتر ترد ها هرکدام مانند یک cpu جدا هستن پس ملاک ما عدد 8 هست نه 4، انگار این کامپوتر هشتا cpu داره )
@DevTwitter | <Mahdi Bagheri/>
یه مفهومی به اسم load داریم که با دستور uptime و یا مستقیم از
/proc/loadavg
میشه اون رو دید توی لینوکس 3 نوع load رو گزارش میده به ترتیب از چپ در یک دقیقه اخیر، پنج دقیقه اخیر و پانزده دقیقه اخیر
اما این load چیه؟ فرض کنین یه cpu یک هسته ای داریم load اگه صفر باشه یعنی cpu بیکاره و تا عدد 1 میزان کار اون رو نشون میده.
اگه عدد بیشتر از 1 باشه مثلا 1.65 یعنی cpu مقدار 65% از کاراش توی صف هستند و اگه 5.5 باشه یعنی 450% از کار هاش توی صف هستند.
اما کامپیوتر های الان cpu های بیش از یه هسته دارن مثلا برای یه cpu هشت هسته ای اگه load avg برابر 12 باشه 50% کار ها در صف هستن و اگه زیر 8 باشه یعنی هیچ کار در صفی نداره (درواقع load رو باید بر تعداد هسته ها تقسیم کرد)
مثل تصویر میتونین با دستور lscpu اطلاعات cpu خودتون رو بدست بیارین عکس یه cpu چهار هسته ای رو نشون میده که هشتا ترد داره (از دید کامپیوتر ترد ها هرکدام مانند یک cpu جدا هستن پس ملاک ما عدد 8 هست نه 4، انگار این کامپوتر هشتا cpu داره )
@DevTwitter | <Mahdi Bagheri/>
❤23👍7🔥2🍌2
سلام و دورد
امروز یه ربات تلگرام با nodejs نوشتم به در خواست تیم مارکتینگ برای اعضای کانال تلگرامی شرکت که خیلی خیلی ساده اس و کاربران فقط میزنن روی قرعه کشی و آیدیشون ثبت میشه برای قرعه کشی و اعلام برنده
و اینکه به ادمین هم امکان خروجی فایل csvمیده تا اسامی رو داشته باشه
لینکشو میذارم دوست داشتید استفاده کنید و خیلی خوشحال میشم اگر فیچری هم مد نظرتون هست بهش اضافه کنم
https://github.com/iamir4g/raffleBot
@DevTwitter | <Amir Farahani/>
امروز یه ربات تلگرام با nodejs نوشتم به در خواست تیم مارکتینگ برای اعضای کانال تلگرامی شرکت که خیلی خیلی ساده اس و کاربران فقط میزنن روی قرعه کشی و آیدیشون ثبت میشه برای قرعه کشی و اعلام برنده
و اینکه به ادمین هم امکان خروجی فایل csvمیده تا اسامی رو داشته باشه
لینکشو میذارم دوست داشتید استفاده کنید و خیلی خوشحال میشم اگر فیچری هم مد نظرتون هست بهش اضافه کنم
https://github.com/iamir4g/raffleBot
@DevTwitter | <Amir Farahani/>
🍌40❤11👍5👎1
در زبان Go مفهومی به نام Goroutine وجود دارد اما Goroutine چیست؟
اول باید بگم که زبان go برعکس زبان جاوااسکریپت و تایپاسکریپت مفهموم Concurrency (همزمانی) را به صورت کاملا واقعی در CPU اجرا میکند در حالی که جاوااسکریپت و تایپاسکریپت اینکار را فقط شبیهسازی میکنند و یکی از دلایل سرعت بالای این زبان همین امر است
یعنی go میتونه دستورات رو در Thread های مختلف CPU به صورت کاملا واقعی اجرا کنه
حالا بریم سراغ مفهوم Goroutine
بخوام به سادهترین شکل ممکن بگم کارش برعکس async/await در زبان جاوااسکریپت هست (البته فقط در ظاهر)
گوروتین میتونه تابع و دستور مورد نظر مارو در یک Thread متفاوت اجرا کنه تا مابقی کد ما متوقف نشه و سایر کدهای ما همزمان اجرا بشه و برنامه منتظر نمونه
یعنی وقتی یه تابعی داریم که زمانبر هست و ما نیازی به خروجی اون تابع در ادامه کد نداریم (مثل لاگ انداختن) از گوروتین استفاده میکنیم تا کل برنامه منتظر اتمام اون تابع نشه
(در عکس یه مثال ساده از گوروتین رو براتون آوردم)
@DevTwitter | <sina khaghani/>
اول باید بگم که زبان go برعکس زبان جاوااسکریپت و تایپاسکریپت مفهموم Concurrency (همزمانی) را به صورت کاملا واقعی در CPU اجرا میکند در حالی که جاوااسکریپت و تایپاسکریپت اینکار را فقط شبیهسازی میکنند و یکی از دلایل سرعت بالای این زبان همین امر است
یعنی go میتونه دستورات رو در Thread های مختلف CPU به صورت کاملا واقعی اجرا کنه
حالا بریم سراغ مفهوم Goroutine
بخوام به سادهترین شکل ممکن بگم کارش برعکس async/await در زبان جاوااسکریپت هست (البته فقط در ظاهر)
گوروتین میتونه تابع و دستور مورد نظر مارو در یک Thread متفاوت اجرا کنه تا مابقی کد ما متوقف نشه و سایر کدهای ما همزمان اجرا بشه و برنامه منتظر نمونه
یعنی وقتی یه تابعی داریم که زمانبر هست و ما نیازی به خروجی اون تابع در ادامه کد نداریم (مثل لاگ انداختن) از گوروتین استفاده میکنیم تا کل برنامه منتظر اتمام اون تابع نشه
(در عکس یه مثال ساده از گوروتین رو براتون آوردم)
@DevTwitter | <sina khaghani/>
❤39👍6🔥3👎2
This media is not supported in your browser
VIEW IN TELEGRAM
اگه زیاد از terminal CLI استفاده میکنید مثل من و میخواهید فایلهای اکسل را بخونید و یا سرچ کنید و .. این ابزار خیلی عالیه. خیلی خوشگل و مرتب فایل ها را نشون میده، امکان سرچ و کپی داره و کلی فیچر دیگه. گیتهابشون را چک کنید.
https://github.com/bgreenwell/xleak/
@DevTwitter | <Mehdi Allahyari/>
https://github.com/bgreenwell/xleak/
@DevTwitter | <Mehdi Allahyari/>
❤12🔥3👎1
داستان خلق Node.js — جایی که یک نارضایتی ساده تبدیل به انقلاب شد
سال ۲۰۰۹، «رایان دال» پشت لپتاپش نشسته بود و به یک ویدیو ساده در وب فکر میکرد:
چرا هنوز مرورگرها نمیتوانند یک فایل را کاملاً غیرهمزمان آپلود کنند؟
چرا برای کوچکترین عملیات I/O باید کل برنامه منتظر بماند؟
و چرا زبانهای سمت سرور هنوز اینقدر سنگین و بلاککننده کار میکنند؟
این سؤالها شاید پیشپاافتاده بهنظر برسند، اما برای دال تبدیل شدند به جرقه یک تغییر بزرگ.
در آن زمان، بیشتر زبانهای سمت سرور مانند PHP، Python یا Ruby یک مشکل مشترک داشتند:
هر درخواست، یک Thread. هر Thread، حافظه زیاد. و هر برنامه، یک سقف محدود برای مقیاسپذیری.
برای دنیایی که سرعت اینترنت داشت بالا میرفت و کاربران همزمان بیشتر میشدند، این مدل دیگر جواب نمیداد.
دال بهجای اینکه مشکل را با سختافزار بیشتر حل کند، از خودش پرسید:
اگر بتوانیم مدل سرور را مثل مرورگر طراحی کنیم چه؟
جایی که همهچیز Event-Driven باشد، بدون بلاک شدن، بدون Threadهای سنگین.
و اینطور شد که یک ایده جسورانه شکل گرفت:
ساخت یک Runtime سبک، سریع، مبتنی بر event loop، و توانمند در مدیریت هزاران اتصال همزمان.
جاوااسکریپت انتخاب شد، نه به خاطر اینکه بهترین زبان جهان بود،
بلکه بهخاطر اینکه یک ویژگی حیاتی داشت:
تک رشتهای (Single-threaded) بودن و مدل رویداد محور طبیعی.
نتیجه؟
در JSConf اروپا، دال برای اولین بار چیزی را معرفی کرد که صنعت وب را تکان داد:
Node.js
با ارائهی مفهومی جدید از ساخت Back-end —
جایی که شبکهسازی، I/O، و اجرای همزمان،
بدون Threadهای سنگین
و با سرعت باورنکردنی قابل انجام بود.
ابزار Node.js به سرعت از یک تجربه آزمایشگاهی تبدیل شد به ابزاری که امروز موتور بسیاری از شرکتهای بزرگ دنیاست: Netflix، Uber، PayPal، LinkedIn و دهها نام دیگر.
این داستان از این جهت الهامبخش است که نشان میدهد:
گاهی یک نارضایتی ساده در ذهن یک برنامهنویس،
میتواند آیندهی یک صنعت را تغییر دهد.
@DevTwitter | <Ali Yousefi/>
سال ۲۰۰۹، «رایان دال» پشت لپتاپش نشسته بود و به یک ویدیو ساده در وب فکر میکرد:
چرا هنوز مرورگرها نمیتوانند یک فایل را کاملاً غیرهمزمان آپلود کنند؟
چرا برای کوچکترین عملیات I/O باید کل برنامه منتظر بماند؟
و چرا زبانهای سمت سرور هنوز اینقدر سنگین و بلاککننده کار میکنند؟
این سؤالها شاید پیشپاافتاده بهنظر برسند، اما برای دال تبدیل شدند به جرقه یک تغییر بزرگ.
در آن زمان، بیشتر زبانهای سمت سرور مانند PHP، Python یا Ruby یک مشکل مشترک داشتند:
هر درخواست، یک Thread. هر Thread، حافظه زیاد. و هر برنامه، یک سقف محدود برای مقیاسپذیری.
برای دنیایی که سرعت اینترنت داشت بالا میرفت و کاربران همزمان بیشتر میشدند، این مدل دیگر جواب نمیداد.
دال بهجای اینکه مشکل را با سختافزار بیشتر حل کند، از خودش پرسید:
اگر بتوانیم مدل سرور را مثل مرورگر طراحی کنیم چه؟
جایی که همهچیز Event-Driven باشد، بدون بلاک شدن، بدون Threadهای سنگین.
و اینطور شد که یک ایده جسورانه شکل گرفت:
ساخت یک Runtime سبک، سریع، مبتنی بر event loop، و توانمند در مدیریت هزاران اتصال همزمان.
جاوااسکریپت انتخاب شد، نه به خاطر اینکه بهترین زبان جهان بود،
بلکه بهخاطر اینکه یک ویژگی حیاتی داشت:
تک رشتهای (Single-threaded) بودن و مدل رویداد محور طبیعی.
نتیجه؟
در JSConf اروپا، دال برای اولین بار چیزی را معرفی کرد که صنعت وب را تکان داد:
Node.js
با ارائهی مفهومی جدید از ساخت Back-end —
جایی که شبکهسازی، I/O، و اجرای همزمان،
بدون Threadهای سنگین
و با سرعت باورنکردنی قابل انجام بود.
ابزار Node.js به سرعت از یک تجربه آزمایشگاهی تبدیل شد به ابزاری که امروز موتور بسیاری از شرکتهای بزرگ دنیاست: Netflix، Uber، PayPal، LinkedIn و دهها نام دیگر.
این داستان از این جهت الهامبخش است که نشان میدهد:
گاهی یک نارضایتی ساده در ذهن یک برنامهنویس،
میتواند آیندهی یک صنعت را تغییر دهد.
@DevTwitter | <Ali Yousefi/>
1❤57👎10🍌8👍4
This media is not supported in your browser
VIEW IN TELEGRAM
وقتی با مدلهای LLM و سیستم های ایجنتیک کار میکنید یکی از مهمترین کارهایی که باید انجام بدید/بنظرم مهمترین کار اینه که پرفورمنس سیستم را ارزیابی کنید یا به اصطلاح evaluation انجام بدید. اگه بدون evaluation ایجنت میسازید به هیچ دردی نمیخوره!
این منبع ارزشمند/۵۰ صفحه مطلب را حتما بخونید.
Link: https://huggingface.co/spaces/OpenEvals/evaluation-guidebook#what-is-model-evaluation-about
@DevTwitter | <Mehdi Allahyari/>
این منبع ارزشمند/۵۰ صفحه مطلب را حتما بخونید.
Link: https://huggingface.co/spaces/OpenEvals/evaluation-guidebook#what-is-model-evaluation-about
@DevTwitter | <Mehdi Allahyari/>
❤13👍2🔥1