Anophel | آنوفل

🖥در دیتابیس Database Replication vs Backup؛ این دوتا یکی نیستن! خیلی‌ها فکر می‌کنن اگه دیتابیس رو روی چند سرور داشته باشن، دیگه بکاپ لازم نیست. اشتباهه. ✅خب Replication یعنی چی؟ رپلیکشن Replication یعنی تغییرات دیتابیس رو به یک یا چند دیتابیس دیگه هم منتقل کنیم. مثلاً: ┌──────────────┐ │ Primary DB │ └──────┬───────┘ │ ┌──────┴───────┐ │ │ ▼ ▼ Replica #1 Replica #2 مثلاً وقتی روی Primary یک INSERT انجام میشه، همون تغییر به Replicaها منتقل میشه. کاربرد اصلیش: ✅افزایش Availability ✅و Failover ✅تقسیم Readها بین چند سرور ✅کاهش Downtime ✅داشتن دیتابیس آماده برای جایگزینی Primary اما یه مشکل بزرگ داره: Replication تاریخچه نیست؛ آینه‌ست. فرض کن به اشتباه اینو اجرا کنی: DROP TABLE users; اگر Replication فعال باشه، این دستور ممکنه روی Replicaها هم اعمال بشه! یعنی خیلی سریع داری اشتباهت رو روی چند سرور تکثیر می‌کنی :)) 💾بکاپ Backup یعنی چی؟ بکاپ Backup یعنی از دیتابیس یک نسخه قابل بازیابی در یک نقطه زمانی مشخص داشته باشیم. مثلاً: Monday → Backup Tuesday → Backup Wednesday → Backup Thursday → Backup حالا اگر چهارشنبه ساعت 15:00 یه اتفاق خرابکارانه افتاد، می‌تونی دیتابیس رو به وضعیت قبل از اون اتفاق برگردونی. بکاپ Backup برای چیزهایی مثل این حیاتی محسوب میشه: ✅حذف اشتباهی اطلاعات ✅خراب شدن دیتابیس ✅و Ransomware ✅خراب شدن Storage ✅خطای برنامه ✅و Human Error ✅و Disaster Recovery 💬 پس فرقشون چیه؟ Replication = Availability یعنی: «اگر این سرور خراب شد، سریع یکی دیگه داشته باشم.» Backup = Recovery یعنی: «اگر اطلاعات خراب یا حذف شد، بتونم به یک نسخه سالم قبلی برگردم.» ✅ بهترین حالت؟ هر دو! یک معماری ساده می‌تونه این شکلی باشه: Application │ ▼ ┌─────────────┐ │ Primary DB │ └──────┬──────┘ │ Replication ┌───────┴───────┐ ▼ ▼ ┌──────────┐ ┌──────────┐ │ Replica 1│ │ Replica 2│ └──────────┘ └──────────┘ + ┌──────────┐ │ Backup │ └────┬─────┘ │ ▼ Remote Storage و حتی بهتر: Backup رو روی همون سروری که دیتابیس قرار داره نگه ندار. چون اگر خود سرور یا Storage نابود بشه، هم Database رو از دست دادی هم Backup رو. مثلاً: Database Server │ │ Backup ▼ Object Storage / Remote Server ⸻ 🟡 قانون ساده: Replication برای زنده موندنه. Backup برای برگشتنه. پس: Replication جای Backup نیست؛ Backup هم جای Replication نیست. برای یک سیستم Production جدی، معمولاً باید هر دو رو در کنار هم داشته باشی. #Anophel #database #Replication #Backup #mysql

🚀‌‌تایپ اسکریپت TypeScript 7؛ تایپ‌اسکریپت بالاخره Turbo شد بله TypeScript 7 منتشر شد و این نسخه فقط یه آپدیت معمولی نیست؛ کامپایلر TypeScript از JavaScript به Go پورت شده. نتیجه؟ سرعتی که واقعاً محسوسه: ✅ حدود 8 تا 12 برابر سریع‌تر در buildهای بزرگ ✅ مصرف حافظه کمتر ✅ استفاده از multithreading و parallelism ✅ بهبود محسوس سرعت type-check و editor tooling ✅ پشتیبانی از LSP برای integration بهتر با ادیتورها مثلاً روی پروژه‌ی خود VS Code: TypeScript 6 → 125.7s TypeScript 7 → 10.6s یعنی تقریباً 11.9x سریع‌تر. حتی load شدن پروژه در ادیتور هم از حدود یک دقیقه به نزدیک 10 ثانیه رسیده. نکته جالب‌تر اینه که Microsoft این کامپایلر رو از صفر با منطق متفاوت نساخته؛ بخش زیادی از implementation قبلی به‌صورت faithful به Go منتقل شده تا رفتار و type-checking تا حد ممکن سازگار بمونه. برای نصب هم مثل همیشه: npm install -D typescript پس اگر پروژه TypeScript داری، احتمالاً یکی از جذاب‌ترین آپدیت‌هایی که باید تستش کنی همینه. و خب… و TypeScript 7 با Go نوشته شده. 💢بالاخره Go یه جایی هم به فرانت‌اند رسید :) #آنوفل #Anophel #Go #typescript

دسترسی رایگان 14 روزه به تمام مدل های zed code ادیتور Zed اشتراک ۱۴ روزه Pro خودش رو به همراه ۲۰ دلار اعتبار رایگان ارائه میده! ​مراحل دریافت: وارد سایت بشید تیک Free trial پلن پرو رو بزنید zed.dev/pricing با اکانت گیتهاب ( قدمت حداقل 30 روز ) لاگین کنید ✍️ CypherDeveloper

🐱مدیریت تعارض تو تیم‌های برنامه‌نویسی تو تیم‌های نرم‌افزاری، تعارض معمولاً از جایی شروع می‌شه که کسی فکر می‌کنه «من درست می‌گم و بقیه اشتباه می‌کنن». مثلاً یه بار سر انتخاب معماری با همکارم چند روز درگیر بودیم. من می‌گفتم این روش مقیاس‌پذیره، اون می‌گفت پیچیده‌ست و زمان‌بر. جلسه بعد جلسه بحث بالا می‌گرفت و هیچ‌کدوم کوتاه نمیومدیم. آخرش فهمیدیم مشکل اصلیمون این نبود که کدوم روش بهتره؛ مشکل این بود که هیچ‌کدوم‌مون درست گوش نداده بودیم به دغدغه‌ی طرف مقابل. تو محیط برنامه‌نویسی تعارض‌ها معمولاً از این جنس‌ان: • سر استایل کد و استانداردها • سر انتخاب تکنولوژی • سر اولویت فیچرها • یا حتی سر اینکه کد ریویو باید سخت‌گیرانه باشه یا نه ✅چیزایی که کمک می‌کنه: • اول بفهمی طرف مقابل از چی می‌ترسه یا نگران چیه (نه فقط چی می‌گه) • به جای «تو اشتباه می‌کنی» بگی «من این نگرانی رو دارم که…» • اگه بحث فنی قفل شد، یه نفر سوم بی‌طرف بیار وسط یا روی دیتا و تست تصمیم بگیرین • گاهی وقتا کوتاه اومدن، قوی‌تر بودنه؛ مخصوصاً وقتی موضوع حیاتی نیست تعارض بد نیست. تعارضی بد می‌شه که تبدیل به لجبازی شخصی بشه و تیم رو از هدف اصلیش دور کنه. 💬شما تو تیمتون معمولاً سر چی بیشتر به مشکل می‌خورین؟ معماری، کد ریویو، یا اولویت‌بندی کارها؟ #برنامه‌نویسی #مدیریت_تعارض #SoftSkills #تیم_نرم‌افزاری #کدنویسی #آنوفل #Anophel

💢 یادگیری Concurrency در Go، به شکل Interactive! اگه با Go کار می‌کنی، احتمالاً با مفاهیمی مثل Goroutine، Channel، Worker Pool، Pipeline و الگوهای مختلف Concurrency سر و کار داشتی. اما یادگیری این مفاهیم فقط با خوندن تئوری همیشه راحت نیست. Go Concurrency Explorer یه محیط تعاملیه که برای یادگیری الگوهای Concurrency در Go ساخته شده؛ جایی که می‌تونی مفاهیم رو به شکل Visual و Interactive تجربه کنی و بهتر متوجه بشی که پشت پرده چه اتفاقی می‌افته. 🔗 https://www.concurrency.rocks برای کسایی که می‌خوان Concurrency در Go رو عمیق‌تر یاد بگیرن، مخصوصاً وقتی تفاوت بین الگوهای مختلف رو می‌خواید واقعاً درک کنید، می‌تونه ابزار جالبی باشه. #Go #Golang #Concurrency #GoLang #Programming #SoftwareEngineering #Backend #Developer #LearningGo #anophel

🐧 کدوم توزیع لینوکس برای چه کسی مناسبه؟ یکی از سوال‌های همیشگی موقع مهاجرت به لینوکس: «کدوم Linux Distribution رو نصب کنم؟» جوابش ساده‌ست: بستگی داره با سیستم‌عاملت چه کار می‌کنی. بیاید چندتا از معروف‌ترین‌ها رو ببینیم: 💻 Ubuntu — برای شروع و استفاده عمومی مناسب برای: • تازه‌کارهای لینوکس • برنامه‌نویسی • استفاده روزمره • سرورها و Cloud • کسانی که دنبال دردسر کمتر هستن مزیت: جامعه کاربری خیلی بزرگ + مستندات و آموزش فراوان + پشتیبانی نرم‌افزاری خوب اگر اولین باره Linux نصب می‌کنی و نمی‌دونی از کجا شروع کنی → Ubuntu انتخاب امنیه. 💻 Linux Mint — لینوکس برای مهاجرت راحت از Windows مناسب برای: • کاربران Windows • سیستم‌های قدیمی‌تر • استفاده روزمره • کسانی که Desktop سنتی می‌خوان محیط کاربری آشنا، تنظیمات ساده و تجربه‌ای نزدیک‌تر به چیزی که کاربران Windows انتظار دارن. اگر فقط می‌خوای «ویندوز رو کنار بذاری و راحت کار کنی» → Mint گزینه خوبیه. 💻 Fedora — برای Developerها و تکنولوژی‌های جدید مناسب برای: • برنامه‌نویس‌ها • Developerها • کسانی که پکیج‌های نسبتاً جدید می‌خوان • علاقه‌مندان به تکنولوژی‌های جدید Linux Fedora معمولاً بین ثبات و جدید بودن تعادل خوبی برقرار می‌کنه. اگر Developer هستی و می‌خوای محیط مدرن‌تری داشته باشی → Fedora رو ببین. 💻 Arch Linux — برای کسی که می‌خواد Linux رو واقعاً بشناسه مناسب برای: • کاربران حرفه‌ای • Developerها • علاقه‌مندان به Linux • کسانی که کنترل کامل سیستم رو می‌خوان اینجا خبری از «همه‌چیز از قبل آماده‌ست» نیست. خودت انتخاب می‌کنی: • چه Kernelای • چه Desktop Environment یا Window Managerای • چه سرویس‌هایی • چه پکیج‌هایی • و سیستم دقیقاً چطور کار کنه مزیت بزرگ: کنترل و شخصی‌سازی فوق‌العاده نکته: برای شروع Linux الزاماً بهترین گزینه نیست. 💻 Debian — برای Stability مناسب برای: • Server • سیستم‌های Production • کسانی که Stability براشون مهم‌تر از جدید بودن پکیج‌هاست • کاربران حرفه‌ای تمرکز اصلی Debian روی اینه که سیستم قابل اعتماد و پایدار باشه. اگر می‌گی: «آخرین نسخه پکیج مهم نیست، فقط می‌خوام سیستم کار کنه.» → Debian 💻 openSUSE Tumbleweed — Rolling Release با تمرکز روی Stability مناسب برای: • کاربران حرفه‌ای • Developerها • کسانی که Rolling Release می‌خوان • کسانی که ابزارهای مدیریتی قدرتمند می‌خوان Tumbleweed دائماً به‌روز می‌شه، ولی تلاش می‌کنه قبل از انتشار آپدیت‌ها تست‌های زیادی انجام بشه. 💻 Kali Linux — برای Cybersecurity مناسب برای: • Penetration Testing • Security Research • Digital Forensics • Ethical Hacking Kali برای استفاده روزمره طراحی نشده. اگر فقط به خاطر اینکه «هکرها از Kali استفاده می‌کنن» می‌خوای نصبش کنی… نکن. برای یادگیری Linux و استفاده روزمره، توزیع‌های معمولی انتخاب بهتری هستن. 😀 Alpine Linux — برای Container و سیستم‌های Minimal مناسب برای: • Docker • Container • سیستم‌های Embedded • محیط‌هایی که حجم کم اهمیت داره Alpine به خاطر حجم کم و طراحی Minimal خودش محبوبه. به‌خصوص در دنیای Containerها زیاد باهاش مواجه می‌شید. خلاصه سریع 🐹 تازه‌کار: Ubuntu / Mint 💻 Developer: Fedora / Ubuntu / Arch 🚀 Linux Enthusiast: Arch 🔐 Stable Server: Debian 🔵 Rolling Release: Arch / openSUSE Tumbleweed 🔐 Cybersecurity: Kali 👨‍💻 Containers: Alpine 🟡 سیستم‌های قدیمی: Linux Mint XFCE / Xubuntu 🐱اما یک نکته مهم: هیچ Distributionای ذاتاً «بهترین Linux» نیست. بهترین توزیع = توزیعی که برای نیاز تو مناسب‌تره. ممکنه برای یک نفر Arch بهترین انتخاب باشه و برای نفر دیگه Ubuntu. حتی ممکنه یک Developer روی Fedora کار کنه، سرورهاش Debian باشن و Containerهاش Alpine. پس دفعه بعد که کسی پرسید: «بهترین Linux Distribution چیه؟» جواب بده: «برای چی؟» 🐧 #anophel #برنامه_نویسی #لینوکس #linux #arch

⭐️چطور به ۵۰ میلیون کاربر نوتیفیکیشن بفرستیم؟ فرض کن یک اپلیکیشن داریم با ۵۰ میلیون کاربر فعال و می‌خواهیم وقتی اتفاق مهمی افتاد، به همه‌شان Push Notification بفرستیم. اولین راهی که ممکن است به ذهن برسد، Polling است: هر گوشی مثلاً هر ۲۰ ثانیه از سرور بپرسد: «نوتیفیکیشن جدید دارم؟» اما در مقیاس ۵۰ میلیون دستگاه، این روش خیلی سریع تبدیل به فاجعه می‌شود. ۵۰ میلیون دستگاه ÷ ۲۰ ثانیه = ۲.۵ میلیون Request در هر ثانیه یعنی حتی اگر هیچ نوتیفیکیشنی هم وجود نداشته باشد، سرور باید دائماً با ۲.۵ میلیون درخواست بی‌فایده در ثانیه سروکله بزند. از طرف دیگر، این Polling باعث مصرف بیشتر باتری و Network دستگاه‌ها هم می‌شود. ⭐️راه بهتر: Push Notification اینجاست که سرویس‌هایی مثل Firebase Cloud Messaging (FCM) وارد می‌شوند. به جای اینکه ۵۰ میلیون موبایل مدام از سرور ما سؤال کنند، معماری را برعکس می‌کنیم: Your Backend │ │ Publish Event ▼ FCM / PubSub │ ┌─────────┼─────────┐ ▼ ▼ ▼ 📱 📱 📱 User 1 User 2 User 3 │ │ │ └────── ... ────────┘ 50M Users سرور ما لازم نیست برای تک‌تک ۵۰ میلیون کاربر یک درخواست جداگانه ارسال کند. ما یک Event / Message منتشر می‌کنیم و سیستم Messaging مسئول Fan-out کردن آن برای کاربران مقصد می‌شود. 🫶و Pub/Sub چرا مهم است؟ فرض کن یک موضوع داریم: breaking-news کاربران مختلف به این Topic Subscribe شده‌اند. حالا وقتی خبری منتشر می‌شود، Backend فقط یک پیام به Topic می‌دهد: publish("breaking-news", notification) و زیرساخت Messaging آن را بین Subscriberها توزیع می‌کند. این مدل خیلی بهتر از این است که خودمان چیزی شبیه این بنویسیم: for user in 50_000_000 { sendNotification(user) } چون در این حالت، مسئولیت توزیع عظیم پیام از Application Server خودمان خارج می‌شود و به زیرساختی سپرده می‌شود که برای همین کار طراحی شده است. ⭐️اما یک نکته جالب‌تر! حتی وقتی Push Notification ارسال می‌شود، لزوماً همه کاربران بلافاصله روی سرور ما Request نمی‌زنند. مثلاً اگر کاربر روی Notification کلیک کند: FCM │ ▼ 📱 User │ │ Tap ▼ Your App │ │ API Request ▼ Your Backend در این لحظه است که می‌توانیم یک Traffic Spike ببینیم. یعنی اگر تعداد زیادی کاربر همزمان Notification را ببینند و روی آن کلیک کنند، ناگهان تعداد زیادی Request به Backend خودمان می‌رسد. 🧠پس در معماری واقعی فقط Push کردن مهم نیست؛ باید برای Burst Traffic بعد از Push هم آماده باشیم. ⭐️خلاصه در مقیاس کوچک شاید Polling کاملاً قابل قبول باشد. اما وقتی به ده‌ها میلیون Device می‌رسیم: Polling: 50M devices × request every 20s = 2.5M requests/sec که بخش بزرگی از آن‌ها فقط می‌گویند: "Nothing new." در عوض با Push + Pub/Sub: Backend │ ▼ Publish Event │ ▼ Messaging Infrastructure │ ├──► User 1 ├──► User 2 ├──► User 3 └──► ... 50M users بک اند ما فقط Event را منتشر می‌کند و سیستم Messaging وظیفه Fan-out را انجام می‌دهد. 😃درس اصلی System Design اینجاست: وقتی تعداد Clientها خیلی زیاد می‌شود، به جای اینکه همه Clientها دائماً از Server سؤال کنند، بهتر است Server فقط هنگام رخ دادن Event، پیام را Push کند. و البته در چنین مقیاسی باید به Pub/Sub، Fan-out، Message Priority، Rate Limiting، Retry، Backpressure و Traffic Spike هم فکر کرد. #آنوفل #برنامه_نویسی #anophel #system_design

🚨 یک اتفاق امنیتی مهم در دنیای Arch Linux 💻اگر از Arch استفاده می‌کنید احتمالاً اسم AUR را شنیده‌اید. AUR (Arch User Repository) یکی از جذاب‌ترین بخش‌های Arch است که به کاربران اجازه می‌دهد پکیج‌هایی را که در مخزن رسمی نیستند نصب کنند؛ اما یک تفاوت مهم دارد: این پکیج‌ها توسط خود جامعه نگهداری می‌شوند، نه تیم رسمی Arch. اخیراً چند مورد سوءاستفاده از AUR گزارش شده؛ مهاجم‌ها بعضی پکیج‌های بدون maintainer را تصاحب کرده‌اند و تغییرات مخرب داخل آن‌ها قرار داده‌اند. به همین دلیل تیم Arch موقتاً قابلیت «Adopt کردن» پکیج‌های orphan در AUR را متوقف کرده تا جلوی ادامه این حملات گرفته شود. ⚙نکته مهم: AUR مثل مخزن رسمی Arch نیست. وقتی چیزی از AUR نصب می‌کنید، در واقع دارید یک اسکریپت PKGBUILD نوشته‌شده توسط یک کاربر دیگر را اجرا می‌کنید. اگر Arch دارید: ⭐️ قبل از نصب پکیج‌های AUR، PKGBUILD را بررسی کنید. ⭐️ پکیج‌های ناشناس یا تازه تغییر مالکیت داده‌شده را با احتیاط نصب کنید. ⭐️ هر چیزی که از اینترنت می‌گیرید را مثل اجرای یک اسکریپت خارجی در نظر بگیرید. قدرت Arch دقیقاً از همین آزادی می‌آید؛ اما این آزادی همیشه با مسئولیت بیشتر همراه است. 🐧  #anophel #arch #linux

🧠 یه اشتباه رایج تو طراحی سیستم‌های نوتیفیکیشن اینه که Event Ingestion و Notification Dispatch رو یکی در نظر می‌گیریم. یعنی هر Event که وارد سیستم میشه، همون لحظه تبدیل به یک Notification میشه. در نگاه اول ساده و منطقیه، ولی وقتی سیستم بزرگ‌تر میشه، مشکل خودش رو نشون میده. فرض کنید یک Webhook دارید. یک سرویس مشکل پیدا کرده و Provider شروع به Retry کردن درخواست‌ها می‌کنه. در چند دقیقه ممکنه ۳۰ تا Event مشابه دریافت کنید. اگر معماری اینطوری باشه: Event → Notification کاربر در نهایت ۳۰ تا Notification مشابه دریافت می‌کنه. اما نکته مهم اینه که: Event با Notification یکی نیست. Event یعنی: «یک اتفاق در سیستم رخ داده.» Notification یعنی: «یک چیزی وجود دارد که کاربر باید از آن مطلع شود.» این دو تا lifecycle متفاوت دارند. راه بهتر اینه که بین این دو یک لایه میانی قرار بدیم. ابتدا Eventها ingest میشن. بعد یک مرحله Aggregation یا Coalescing داریم که Eventهای مشابه رو کنار هم جمع می‌کنه. مثلاً برای هر Event یک idempotency key تعریف می‌کنیم: resource_id + event_type بعد Eventهای مشابه رو در یک window زمانی نگه می‌داریم. مثلاً ۵ دقیقه. در این بازه هر Retry جدید فقط باعث افزایش count میشه، نه ساخت یک Notification جدید. بعد از پایان window به جای ۳۰ پیام: Service X در ۵ دقیقه گذشته ۳۰ بار retry شد. یک Notification خلاصه و معنی‌دار ساخته میشه. ⭐️مزیتش: 🫶کاهش noise برای کاربر 🫶کاهش فشار روی سیستم Notification 🫶جلوگیری از ارسال پیام‌های تکراری 🫶تجربه کاربری بهتر این الگو فقط برای Webhook نیست. در سیستم‌های Alerting، Monitoring، Billing و تقریباً هر معماری Event-driven با حجم بالا کاربرد داره. خیلی وقت‌ها مشکل سیستم Notification با اضافه کردن Queue یا Retry حل نمیشه؛ مشکل از جایی شروع شده که از اول Event و Notification را دو مفهوم جدا طراحی نکردیم. #Anophel #BackendDevelopment #Microservices #NotificationSystem #Webhooks #Observability #Engineering

😃یکی اومده کل استک یه دستیار هوش مصنوعی رو از صفر با Zig نوشته؛ اسمش هم NullClaw! اعدادش واقعاً عجیبن: 🔻 فقط ۶۷۸ کیلوبایت حجم باینری 🧠حدود ۱ مگابایت RAM مصرف می‌کنه ✔️ کمتر از ۲ میلی‌ثانیه استارت می‌خوره بدون Runtime، بدون Virtual Machine، بدون Framework و حتی بدون Garbage Collector؛ فقط Zig خالص. حالا مقایسه کنید: • OpenClaw برای اجرا به بیش از ۱ گیگابایت RAM نیاز داره. • NanoBot با Python اجرا میشه و بالای ۱۰۰ مگابایت RAM مصرف می‌کنه. • PicoClaw هم حدود ۱۰ مگابایت RAM و Go می‌خواد. اما NullClaw روی یه برد ۵ دلاری با فقط ۱ مگابایت RAM اجرا میشه! داخل همین باینری ۶۷۸ کیلوبایتی هم امکانات کمی نداره: ⭐️پشتیبانی از +۲۲ ارائه‌دهنده AI (OpenAI، Anthropic، Ollama، Groq، DeepSeek و…) ⭐️ اتصال به ۱۳ پیام‌رسان و پلتفرم (تلگرام، دیسکورد، اسلک، واتساپ، iMessage، IRC و…) ⭐️ بیش از ۱۸ ابزار داخلی ⭐️ حافظه هیبریدی (Vector + Keyword Search) ⭐️ سندباکس چندلایه (Landlock، Firejail و Docker) ⭐️ پشتیبانی از Arduino، Raspberry Pi و STM32 ⭐️ MCP، Subagents، Streaming و قابلیت‌های صوتی از نظر معماری هم همه‌چیز ماژولاره؛ ارائه‌دهنده، حافظه، ابزارها و کانال‌ها فقط با تغییر فایل Config قابل تعویض هستن و نیازی به تغییر کد نیست. از نظر امنیت هم کلیدهای API به‌صورت پیش‌فرض با ChaCha20-Poly1305 رمزنگاری میشن. در مجموع: 🫶حدود ۴۵ هزار خط کد Zig 🫶۲,۷۳۸ تست 🫶 فقط وابسته به libc 🫶 کاملاً متن‌باز و رایگان اگه این اعداد دقیق باشن، یکی از جالب‌ترین نمونه‌های استفاده از Zig برای ساخت نرم‌افزارهای AI محسوب میشه. ⭐️ ویدیو: https://x.com/simplifyinAI/status/2081060260593467595/video/1?s=46

🍷برای اینکه مطمئن بشی VPN درست کار(نشتی ip نداره) می‌کنه، می‌تونی از سایت BrowserLeaks استفاده کنید. این سایت IP فعلی، موقعیت تقریبی، اطلاعات شبکه و همچنین تست DNS Leak و WebRTC Leak رو نشون میده تا مطمئن بشی #اطلاعات واقعی اینترنتت لو نمیره. اگر بعد از اتصال به VPN، آی‌پی و DNS نمایش‌داده‌شده مربوط به سرور VPN باشه و نه اینترنت خودت، یعنی اتصال به‌درستی برقرار شده و نشتی وجود نداره. این سایت ها #امنیت سرور و نشت در اپ ها رو نشون میده: https://browserleaks.com/ip https://myip.theazizi.ir/ @xsfilterrnet 👑 @xszapass 🤩

🐝 Hive v0.1.0 منتشر شد! 🚀 اولین نسخه عمومی Hive منتشر شد. این نسخه یک MVP است؛ یعنی شروع مسیر، نه نسخه نهایی. می‌دونیم هنوز: 🐛 باگ‌هایی وجود داره 🔨 نیاز به Refactor و تمیزکاری کد داریم 📚 مستندات کامل آماده نیست فعلاً توان خرید دامنه‌ی .dev و راه‌اندازی سایت مستندات رو نداریم :( پس فعلاً با GitHub و کانال کنار هم پیش می‌ریم. برای رشد Hive خوشحال می‌شیم کمک کنید: 💛 تست کنید 💛 باگ گزارش بدید 💛 در بهبود کد و Refactor کمک کنید 💛 و اگر دوست داشتید حمایت کنید ❤️ ما هم ادامه می‌دیم و نسخه‌های بعدی خیلی بهتر و خفن‌تر خواهند شد. 🚀 این تازه شروع Hive است 🐝 GitHub: https://github.com/HiveSofts/hive-app آموزش‌ها و مستندات ویدیویی: Instagram: @arshiamohammadei Telegram: @aasshiaa @TheRaymondDev

RCE PoC for Redis 6.2.22, 7.4.9, 8.6.4, 8.8.0 اکسپلویتش تازه از تنور در اومده توی ورژن 8.8.2 فیکس شده که همش ۲ساعته ریلیز شده :) https://github.com/berabuddies/redis-poc @TheRaymondDev

✅یکی از کمبودهای قدیمی HTTP بالاخره برطرف شد. 😃متد QUERY که تا همین اواخر در حد Draft بود، از ژوئن ۲۰۲۶ رسماً با RFC 10008 استاندارد شد. اگر با CQRS کار می‌کنید یا سرچ‌های پیچیده (مثل Elasticsearch) دارید، احتمالاً از این خبر خوشتان می‌آید. ⸻ تا امروز برای سرچ‌های پیچیده معمولاً یکی از این دو راه را داشتیم: GET /search?q=golang&page=1 یا POST /search Content-Type: application/json { "query": { ... } } هر کدام یک مشکل اساسی داشتند. ⭐️ GET از نظر HTTP کاملاً مناسب عملیات Read است: Safe Idempotent Cacheable اما همه پارامترها باید داخل URL قرار بگیرند. برای Queryهای پیچیده، مخصوصاً در Elasticsearch، این روش خیلی زود به بن‌بست می‌رسد. ⸻ ⭐️ POST امکان ارسال Body را می‌دهد و تقریباً همه ما سال‌هاست برای Search از آن استفاده می‌کنیم. اما از دید پروتکل، POST یک عملیات عمومی است که ممکن است State سرور را تغییر دهد. در نتیجه: Cacheها معمولاً آن را Cache نمی‌کنند. Retry خودکار همیشه منطقی نیست. از نظر Semantic، برای یک عملیات صرفاً Read انتخاب ایده‌آلی نیست. ⸻ ⭐️حالا QUERY آمده تا دقیقاً این مشکل را حل کند. QUERY /search Content-Type: application/json { "query": { ... } } یعنی: ⭐️ Body دارد. ⭐️ Safe است. ⭐️ Idempotent است. ⭐️ قابلیت Cache شدن دارد. و مهم‌تر از همه، پروتکل از همان ابتدا می‌داند که این درخواست فقط برای خواندن داده است و هیچ تغییری در State ایجاد نمی‌کند. ⸻ برای طرفداران CQRS این اتفاق واقعاً جذاب است. قبلاً مجبور بودیم بنویسیم: POST /orders/search در حالی که اسم Endpoint می‌گفت Query است، اما Method می‌گفت POST! حالا می‌توانیم بنویسیم: QUERY /orders/search که از نظر Semantic هم کاملاً با معماری CQRS هماهنگ است. ⸻ ⭐️البته یک نکته مهم وجود دارد. هرچند QUERY حالا یک استاندارد رسمی است، اما هنوز بسیاری از Frameworkها، API Gatewayها، Reverse Proxyها، CDNها و ابزارهای مختلف از آن پشتیبانی کامل ندارند. پس فعلاً احتمالاً همچنان POST /search را زیاد خواهید دید؛ اما به مرور زمان انتظار می‌رود QUERY جایگاه واقعی خودش را پیدا کند. به نظر من، این یکی از بهترین تغییراتی است که طی سال‌های اخیر به HTTP اضافه شده؛ چون بالاخره برای «عملیات Read با Body» یک راه‌حل استاندارد داریم. #آنوفل #anophel #http #query #query

💡یک نکته مهم درباره Transaction در MySQL فکر می‌کنی تا وقتی COMMIT نزنی، همه تغییرات داخل Transaction باقی می‌مونن؟ نه همیشه! در MySQL بعضی از دستورات، مخصوصاً دستورات مربوط به تغییر ساختار دیتابیس (DDL)، باعث می‌شن Transaction فعلی به‌صورت خودکار Commit بشه؛ حتی اگر خودت هنوز COMMIT یا ROLLBACK نکرده باشی. مثلاً اجرای دستوراتی مثل: CREATE TABLE ALTER TABLE DROP TABLE می‌تونه مرز Transaction رو بشکنه و تغییرات قبلی رو دائمی کنه. ✅ نتیجه؟ اگر قصد داری عملیاتت کاملاً اتمیک (Atomic) باشه، تغییرات ساختار دیتابیس رو با عملیات CRUD داخل یک Transaction ترکیب نکن. این یکی از نکاتیه که خیلی از توسعه‌دهنده‌ها تا زمانی که به مشکل نخورن، متوجهش نمی‌شن. #MySQL #Database #SQL #Transaction #ACID #DDL #Backend #SoftwareEngineering #Anophel

❓اگر قرار باشد کاربران را بر اساس وضعیت فیلتر کنید، کدام طراحی بهتر است؟ A GET /api/v1/users/active GET /api/v1/users/admins GET /api/v1/users/inactive یا B GET /api/v1/users?status=active GET /api/v1/users?status=admin GET /api/v1/users?status=inactive 🤔شما کدام را انتخاب می‌کنید و چرا؟ پاسخ را در پیام بعدی منتشر می‌کنم… #REST #API #Backend #SystemDesign #SoftwareEngineering #Programming #Anophel

🔥کارت گرفیک RTX 3060 12GB هنوزم قدرتمنده! با کمی بهینه‌سازی روی llama.cpp: 🚀 Qwen3.6-28B-REAP: 52 توکن/ثانیه ⚡Qwen3.6-35B-A3B: 42 توکن/ثانیه هر دو با 128K Context روی یک RTX 3060 12GB اجرا شده‌اند. بهینه‌سازی‌های استفاده‌شده: ✅Turbo KV Cache ✅MoE Offloading ✅تنظیمات بهینه‌ی llama.cpp دستور اجرا: # Qwen3.6-28B-REAP ./llama-server \ -m ./models/Qwen3.6-28B-REAP20-A3B-Q4_K_M.gguf \ --alias qwen36-reap \ -c 131072 -b 1024 -ub 512 -ngl 99 -mmp 0 -t 9 \ -ctk turbo4 -ctv turbo2 -fa 1 --jinja \ --n-cpu-moe 17 --cache-reuse 512 --cache-ram 6144 # Qwen3.6-35B-A3B ./llama-server \ -m ./models/Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf \ --alias qwen36-35a3b \ -c 131072 -b 1024 -ub 512 -ngl 99 -mmp 0 -t 9 \ -ctk turbo4 -ctv turbo2 -fa 1 --jinja \ --n-cpu-moe 24 --cache-reuse 512 --cache-ram 6144 👨‍💻جالبه که با یک GPU میان‌رده هم می‌شه مدل‌های بزرگ رو با سرعت کاملاً قابل استفاده اجرا کرد. #AI #LLM #Qwen #llama_cpp #RTX3060 #OpenSource #Inference #Anophel

https://t.me/boost/anophel