تولدمه :)))

توی این ریپو کدهای سایت فروشگاهی Django رو اوپن‌سورس کردم؛ پروژه‌ای که برای یادگیری معماری درست فروشگاه‌های آنلاین ساختم و روی اصول scalability و clean code پیاده‌سازی شده.

این پروژه دقیقاً چیکار می‌کنه؟
این پروژه برای این طراحی شده که یک فروشگاه آنلاین کامل با تمام قابلیت‌های اساسی رو ارائه بده، از مدیریت محصولات گرفته تا سیستم پرداخت.


معماری و ویژگی‌های تکنیکال:
فریمورک Django با Django ORM و معماری تمیز و قابل گسترش
سیستم سبد خرید با session-based management و مدیریت هوشمند محصولات
سیستم Payment Flow آماده توسعه با قابلیت اتصال آسان به درگاه‌های پرداخت
مدیریت کامل محصولات، دسته‌بندی‌ها، سفارش‌ها و کاربران از طریق پنل ادمین
پیاده‌سازی Authentication & Authorization استاندارد برای امنیت بالا
ساختار modular apps برای توسعه راحت‌تر شامل: products، cart، orders، accounts
استفاده از Template System با صفحات واکنش‌گرا و رابط کاربری مدرن
پروژه Dockerized شده و آماده برای دیپلوی در محیط production


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


این یک پروژه Open Source هست و خوشحال می‌شم اگر دولوپرهای Django، برنامه‌نویس‌های Backend، یا دوستان علاقه‌مند به توسعه فروشگاه‌های آنلاین در توسعه اون شریک بشن.

استارز گیتهاب لطف بزرگیه برای این پروژه.
https://github.com/mehdiseyfie/django_ecommerce_project

@DevTwitter | <Mehdi/>

خجالتم دادید اصلا🥲
پیاماتونم خیلی قشنگ بود ❤️

تفاوت بین اعضای senior و junior فقط در عنوان یا سابقه کاری نیست، بلکه در طرز فکر، شیوه حل مسئله و مهارت‌های نرم (soft skills) آن‌هاست. اعضای senior معمولاً در مواجهه با چالش‌ها به‌جای انتظار برای راهنمایی، خودشان مسیر را پیدا می‌کنند. وقتی پروژه‌ای با مانع روبه‌رو می‌شود، آن‌ها با تحلیل دقیق مسئله، راه‌حل‌های قابل اجرا پیشنهاد می‌دهند و تیم را برای اجرای آن هماهنگ می‌کنند. در مقابل، اعضای junior هنوز در مرحله یادگیری تصمیم‌گیری مستقل و تحلیل موقعیت هستند.

مدیران کلیدی و لیدها باید بیش از هر چیز روی توسعه مهارت‌های نرم خود کار کنند؛ مهارت‌هایی مانند گوش‌دادن فعال، همدلی، مدیریت تعارض و توانایی ارائه بازخورد سازنده. رهبری امروز فقط مدیریت وظایف نیست، بلکه ایجاد فرهنگی است که در آن افراد احساس امنیت کنند تا ایده بدهند، اشتباه کنند و رشد کنند. توانایی حل مسئله، ارتباط مؤثر و تفکر خلاق همان ویژگی‌هایی است که از یک مدیر، رهبر می‌سازد.

علاوه بر مهارت‌های نرم و توانایی حل مسئله، یکی از ویژگی‌های اساسی هر senior و مدیر کلیدی، میل مداوم به یادگیری و مطالعه است. دنیای کار هر روز تغییر می‌کند و کسی که در مسیر رشد واقعی است، باید خود را با این تغییرات هماهنگ کند. مطالعه درباره صنعت جدید، شناخت روندهای بازار و بررسی case study‌های مختلف، نه‌تنها دید استراتژیک فرد را تقویت می‌کند، بلکه باعث می‌شود در تصمیم‌گیری‌ها هوشمندتر عمل کند. یک لید حرفه‌ای می‌داند که یادگیری هیچ‌وقت تمام نمی‌شود، حتی وقتی مسیر شغلی یا حوزه فعالیتش تغییر می‌کند.

و اما پرسش پایانی: آیا آزمون و خطا کار یک senior است؟
پاسخ بله است، اما با تفاوتی مهم — یک senior هم اشتباه می‌کند، اما اشتباهاتش آگاهانه، قابل‌اندازه‌گیری و با هدف یادگیری است. او در مسیر آزمون و خطا حرکت می‌کند، اما هر خطا برایش داده‌ای است که مسیر تصمیم‌های بعدی را دقیق‌تر می‌سازد. آزمون و خطا برای افراد باتجربه ضعف نیست، بلکه بخشی از فرایند رشد و بلوغ حرفه‌ای است.

البته آزمون و خطا برای هر چیزی درست نیست. یک senior باید تفاوت میان تجربه‌سازی و تکرار خطاهای شناخته‌شده را بداند. آزمون و خطا زمانی ارزش دارد که در مسیر کشف و نوآوری باشد، جایی که هنوز استاندارد مشخصی وجود ندارد و خلاقیت می‌تواند مسیر تازه‌ای بسازد. اما وقتی روش‌های استاندارد و بهترین شیوه‌های اجرایی از طریق مطالعه، تجربه و case study‌های متعدد قابل دسترسی‌اند، یک حرفه‌ای باید آن‌ها را بشناسد، به‌کار بگیرد و از تکرار اشتباهات اجتناب کند. در واقع، آزمون و خطا برای یادگیری و خلق است، نه برای بازتولید شکست. یک senior ارزشمند کسی است که بداند چه زمانی باید از تجربه دیگران بیاموزد و چه زمانی باید خودش مسیر جدیدی را بسازد.

@DevTwitter | <Shayan Shalileh/>

#کدبوک

یک راهنمای کاربردی برای درک و پیاده‌سازی الگوریتم‌های مهم در برنامه‌نویسی:

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


* فایل PDF این کتاب رو میتونید از کانال DevBooks که لینکش توی بیو هست دانلود کنید.

@DevTwitter

اگه با این 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/>

چرا 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/>

#کدبوک

مجموعه‌ای از نکات کوتاه و کاربردی برای بهتر شدن در برنامه‌نویسی و کار حرفه‌ای:

- توصیه‌هایی درباره طراحی، نگه‌داری و کیفیت کد
- نکات مهم درباره همکاری تیمی، تست و مستندسازی
- دیدگاه‌هایی از برنامه‌نویس‌های با‌تجربه در حوزه‌های مختلف
- مناسب برای هر توسعه‌دهنده‌ای که می‌خواد عادت‌ها و نگرش حرفه‌ای‌تری پیدا کنه

* فایل PDF این کتاب رو میتونید از کانال DevBooks که لینکش توی بیو هست دانلود کنید.

@DevTwitter

#کوته_نیوز

Bun is joining Anthropic! :)))

@DevTwitter

یک بلاگ جالب خوندم با موضوع "به ماشین یاد بده چطور فکر کنه!". حتما بخونیدش ولی چکیده اش را اینجا مینویسم:
آینده‌ی کار دیگه «حل مسئله» نیست، بلکه «حلِ روشِ حل مسئله» است!

۱/ تصور کنید تو یه مسابقه دیتا ساینس (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/>

پردازش ۴۰ میلیارد رکورد در روز — معماری یک سیستم مقیاس‌پذیر!
خیلی‌ها فکر می‌کنن پردازش ده‌ها میلیارد رکورد در روز فقط از پس غول‌های جهانی مثل Meta یا Netflix برمیاد — اما من یک معماری عملیاتی ساختم که روزانه بالغ بر ۴۰ میلیارد رکورد (معادل تقریبا ۵۰۰ هزار رکورد بر ثانیه) رو از Kafka مصرف و به‌صورت بهینه در ClickHouse ذخیره می‌کنه.

چالش اصلی
بار نامتعادل روی کلاستر توزیع‌شده شلوغ با ۲۰ نود و ۵۲ پارتیشن و عدم تفکیک داده
نیاز به پردازش کم‌تأخیر
حفظ Consistency در حجم عظیم داده

راه‌حل معماری
مصرف‌کننده‌های موازی با Unbounded Channel
پردازش کاملاً Stateless برای scale عمودی و افقی
دسته‌بندی و فشرده‌سازی در Batchهای ۱,۰۰۰,۰۰۰ رکوردی (قابل کانفیگ)
نوشتن مستقیم در ClickHouse با Insertهای ستون‌محور
و Commit offset تنها بعد از نوشتن موفق
جدا کردن مسیر ingest از persist برای افزایش throughput

@DevTwitter | <Amirhossein Maleki/>

وردپرس 6.9 منتشر شد
این نسخه به افتخار هنرمند سرشناس پیانو سبک جاز، Gene Harris نام گذاری شده که شاهد تحولات قابل توجهی می باشد. بیش از ۷۰ بهبود در دسترس‌پذیری و Abilities API برای تعاملات یکپارچه در PHP، REST و زمینه‌های مبتنی بر AI بخشی از ویژگی های این نسخه است.

@DevTwitter | <Alireza Naji/>

اخیرا میخواستم German String رو پیاده سازی کنم اما دیدم واسه Refcount بودن استرینگ و substr گرفتن بدون hardcopy استفاده های بیشتری دارم.
متاسفانه هنوز string literal بدون allocation ساپورت نمیکنه و هنوز ایده ای به ذهنم نرسیده چطور تو 128بیت درستش کنم.

https://github.com/hexorer/libtoypp/blob/main/include/toypp/immutable_string.hpp

@DevTwitter | <Mohsen M./>

وقتی افزونه‌ها کم‌کم تبدیل می‌شن به هم‌تیمی‌های واقعی…

امروز Cline رو روی VS Code تست کردم و رسماً فهمیدم دوران «تنهایی در کدنویسی» داره تموم می‌شه.

این موجود فضاییِ کوچک توی ادیتورم نه‌تنها کد می‌خونه، بلکه ایراد می‌گیره، پیشنهاد می‌ده، فایل می‌سازه، پاک می‌کنه، حتی ترمینال رو هم دستکاری می‌کنه.
یک جورهایی انگار داری با یه دولوپر دیگه pair programming می‌کنی… فقط بدون غر زدن!

دنیای برنامه‌نویسی داره یه لایه جدید پیدا می‌کنه:
کد کمتر، فکر بیشتر.

اگه هنوز امتحانش نکردی… چند قدم مونده تا اینکه واقعاً حس کنی IDEت بامرام‌تر از خیلی از همکاراست.

@DevTwitter | <Amin Hosseini/>

اپ فال حافظ من از یک نیاز خیلی ساده شروع شد؛ همیشه وقتی دور هم جمع می‌شدیم و فال می‌گرفتیم، دوست داشتم یک اپ تمیز و کاملاً فارسی داشته باشم که هم فال تصادفی بده، هم تعبیرش رو قشنگ و خوانا نشان بده برای همین رفتم سراغ Flutter و این پروژه رو ساختم تا روی اندروید، ویندوز و بقیه پلتفرم‌ها هم قابل اجرا باشه و هرکس خواست راحت بتونه ازش استفاده کنه یا توی گیت‌هاب کمک کنه

اسم پروژه only_faleh_hafez هست و داخلش می‌تونی با یک کلیک فال تصادفی از دیوان حافظ بگیری، تعبیر و توضیح اون فال رو بخونی و اگر دنبال شعر خاصی هستی، مستقیم داخل اشعار جست‌وجو کنی رابط کاربری کامل فارسی و راست‌به‌چپ طراحی شده تا حس یک اپ بومی و ساده رو بده، نه یک چیز ترجمه‌شده‌ی عجیب؛ هدفم این بوده که هم برای کاربر معمولی راحت باشه، هم برای دولوپرها اوپن‌سورس و قابل توسعه

لینک ریپو و توضیحات کامل‌تر پروژه:
https://github.com/MMDREZA7/only_faleh_hafez

@DevTwitter | <Ethan Heida/>

چرا 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/>

بهترین روش‌های طراحی REST API
طراحی 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/>

پروژه چت بات با 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/>

اگه کارتون به زمان‌بندی، برنامه‌ریزی یا بهینه‌سازی گیر کرده… 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/>

چطور فشار روی 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/>

سلام و دورد
امروز یه ربات تلگرام با nodejs نوشتم به در خواست تیم مارکتینگ برای اعضای کانال تلگرامی شرکت که خیلی خیلی ساده اس و کاربران فقط میزنن روی قرعه کشی و آیدیشون ثبت میشه برای قرعه کشی و اعلام برنده
و اینکه به ادمین هم امکان خروجی فایل csvمیده تا اسامی رو داشته باشه

لینکشو میذارم دوست داشتید استفاده کنید و خیلی خوشحال میشم اگر فیچری هم مد نظرتون هست بهش اضافه کنم

https://github.com/iamir4g/raffleBot

@DevTwitter | <Amir Farahani/>