Anophel | آنوفل
Open in Telegram
آنوفل | Anophel: دنیای بی پایان امکانات برای برنامه نویسان https://anophel.com پشتیبانی : @anophel_support
Show moreThe country is not specifiedThe category is not specified
271
Subscribers
No data24 hours
-17 days
-330 days
Data loading in progress...
Similar Channels
No data
Any problems? Please refresh the page or contact our support manager.
Tags Cloud
No data
Any problems? Please refresh the page or contact our support manager.
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
September '26
September '26
+1
in 0 channels
August '26
+12
in 0 channels
Get PRO
July '26
+59
in 1 channels
Get PRO
June '26
+228
in 1 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 07 September | 0 | |||
| 06 September | 0 | |||
| 05 September | 0 | |||
| 04 September | 0 | |||
| 03 September | 0 | |||
| 02 September | 0 | |||
| 01 September | +1 |
Channel Posts
Repost from یک برنامه نویس تنبل
🔶 خالق ++C، بیارنه استروستروپ، در گفتگوی اخیر خود ایده جایگزینی زبان های برنامه نویسی با زبان طبیعی را احمقانه دانست و نگاه متفاوتی به تبِ کد نویسی با هوش مصنوعی ارائه داد.
کد های تولید شده با هوش مصنوعی ناکارآمد، بیشازحد حجیم (Bloated) و پر از رخنههای امنیتی و باگ هستند. اعتبارسنجی و تأیید چنین کد هایی کابوس است؛ تا جایی که برنامه نویسان ارشد ترجیح میدهند بازنشسته شوند تا اینکه ناظر کدی باشند که با یک تغییر کوچک در پرامپت، زیرو رو میشود.
شاید ۷۰ یا ۸۰ درصد نرم افزار های دنیا کد های پیش پا افتاده و غیر حساس باشند، اما آن ۱۰ تا ۲۰ درصدِ بحرانی که عملکرد بالا (Performance) و پایداری ایمن (Safety-critical) میخواهند، جایی است که جهان روی آن میچرخد و هوش مصنوعی توان نوشتن آنها را ندارد.
زبان طبیعی ذاتاً مبهم است و برای شعر یا گفتگو طراحی شده، در حالی که مهندسی نرمافزار متکی بر تجرید دقیق (Abstraction) و منطق بدون ابهام است؛ به همین دلیل، انسان ها همچنان کد خواهند نوشت.
#خبر
@TheRaymondDev
| 2 | 🔐 RSA-260 شکسته شده؟ این توییت دقیقاً چی میگه؟
امروز یه توییت دیدم که فقط نوشته بود:
4397328654844826923795068102505872571721883526553349659561256924505973939597593482272505698004801207988043088656411102133523080581 divides RSA-260
https://x.com/penlume/status/2095372672356212876?s=46
شاید در نگاه اول هیچ مفهومی نداشته باشه، ولی پشت همین یک جمله یک مفهوم خیلی جالب در رمزنگاری وجود داره.
بیایید از صفر ببینیم قضیه چیه.
RSA به چی تکیه میکنه؟
یکی از ایدههای اصلی RSA اینه:
ضرب کردن دو عدد اول بزرگ آسونه، ولی پیدا کردن اون دو عدد از حاصل
ضربشون خیلی سخته.
مثلاً:
61 × 53 = 3233
اگر بهت 61 و 53 رو بدم، ضربشون راحت انجام میشه.
اما اگر فقط 3233 رو داشته باشی و بگم:
3233 = ? × ?
باید فاکتورهای اولش رو پیدا کنی:
3233 = 61 × 53
RSA همین ایده رو در ابعاد بسیار بزرگ استفاده میکنه.
RSA-260 چیه؟
RSA-260 یک عدد بسیار بزرگ، حدوداً 260 رقم دهدهی، از مجموعهی چالشهای فاکتورگیری RSA است.
این عدد از ضرب دو فاکتور بزرگ ساخته شده:
N = P × Q
مشکل اینجاست که پیدا کردن P و Q از روی N بسیار سخت است.
حالا برسیم به اون توییت
عدد داخل توییت تقریباً 130 رقم داره.
نویسنده گفته:
D divides RSA-260
کلمهی مهم اینجا divides هست.
یعنی:
RSA-260 % D = 0
یا سادهتر:
RSA-260 بدون هیچ باقیماندهای بر این عدد تقسیم میشود.
اگر این عدد واقعاً یکی از دو فاکتور اصلی RSA-260 باشد، قضیه خیلی جدی میشود:
RSA-260
│
├── D
│
└── Q
یعنی:
RSA-260 = D × Q
و با داشتن D، فاکتور دیگر هم خیلی راحت به دست میآید:
Q = RSA-260 / D
چرا این مهمه؟
چون در RSA، اگر P و Q را داشته باشیم، میتوانیم اطلاعات لازم برای ساختن private key را محاسبه کنیم.
به شکل ساده:
N = P × Q
↓
Factorization
↓
P, Q
↓
Private Key
بنابراین اگر یک RSA modulus واقعاً factor شود، امنیت کلیدی که به آن modulus وابسته است عملاً از بین میرود.
اما یک نکته مهم!
اینکه کسی در توییتر نوشته:
D divides RSA-260
به تنهایی اثبات نمیکند که RSA-260 شکسته شده.
باید خود N را داشته باشیم و واقعاً بررسی کنیم:
N % D == 0
و بعد فاکتور دوم را حساب کنیم و ببینیم آیا فاکتورها معتبر هستند یا نه.
و «RSA شکسته شد» یعنی RSA کلاً مرده؟
نه!
اگر RSA-260 واقعاً factor شده باشد، به این معنی نیست که تمام RSAهای دنیا شکسته شدهاند.
مثلاً:
RSA-260
↓
~260 decimal digits
در حالی که RSA-2048:
2048 bits
~617 decimal digits
دارد.
بنابراین factor شدن یک modulus کوچکتر لزوماً به معنی توانایی factor کردن RSA-2048 نیست.
خلاصه
یک جملهی خیلی کوتاه در توییتر:
D divides RSA-260
ممکنه در واقع یعنی:
RSA-260 = D × Q
و اگر D واقعاً یکی از دو فاکتور اول باشد، یعنی factorization یک RSA بزرگ انجام شده.
همین مسئلهی به ظاهر ساده، یکی از پایههای امنیت RSA رو نشون میده:
محاسبهی P × Q آسانه؛ پیدا کردن P و Q از روی حاصلضرب، بخش سخت ماجراست.
و دقیقاً به همین دلیل چنین توییتی برای آدمهای حوزهی cryptography میتونه خیلی هیجانانگیز باشه. | 31 |
| 3 | One thing that is easy to get wrong when building latency metrics:
You don’t necessarily need to store every request latency.
Imagine a service handling millions of requests. If you collect every latency value just to calculate p95, p99, or p99.9 later, your memory usage becomes proportional to the number of requests you’re observing.
That’s where streaming data structures such as HDR Histogram and t-digest become useful.
Instead of keeping the raw samples, they maintain a compact representation of the observed distribution while new measurements continuously arrive.
Conceptually:
Request → measure latency → update distribution → discard sample
Rather than:
Request → measure latency → store sample → store sample → store sample → calculate percentile later
This makes percentile metrics much more practical for high-throughput systems.
It also changes how I think about observability pipelines: raw measurements are not always the right thing to retain. Sometimes the useful information is the distribution itself.
For latency-heavy systems, p99 isn’t just a number you calculate at the end. It’s something you can maintain continuously as traffic flows through the system.
#go | 59 |
| 4 | 🖥در دیتابیس 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 | 69 |
| 5 | 🚀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 | 57 |
| 6 |  +1دسترسی رایگان 14 روزه به تمام مدل های zed code
ادیتور Zed اشتراک ۱۴ روزه Pro خودش رو به همراه ۲۰ دلار اعتبار رایگان ارائه میده!
مراحل دریافت: وارد سایت بشید تیک Free trial پلن پرو رو بزنید zed.dev/pricing با اکانت گیتهاب ( قدمت حداقل 30 روز ) لاگین کنید
✍️ CypherDeveloper | 71 |
| 7 | 🐱مدیریت تعارض تو تیمهای برنامهنویسی
تو تیمهای نرمافزاری، تعارض معمولاً از جایی شروع میشه که کسی فکر میکنه «من درست میگم و بقیه اشتباه میکنن».
مثلاً یه بار سر انتخاب معماری با همکارم چند روز درگیر بودیم. من میگفتم این روش مقیاسپذیره، اون میگفت پیچیدهست و زمانبر. جلسه بعد جلسه بحث بالا میگرفت و هیچکدوم کوتاه نمیومدیم. آخرش فهمیدیم مشکل اصلیمون این نبود که کدوم روش بهتره؛ مشکل این بود که هیچکدوممون درست گوش نداده بودیم به دغدغهی طرف مقابل.
تو محیط برنامهنویسی تعارضها معمولاً از این جنسان:
• سر استایل کد و استانداردها
• سر انتخاب تکنولوژی
• سر اولویت فیچرها
• یا حتی سر اینکه کد ریویو باید سختگیرانه باشه یا نه
✅چیزایی که کمک میکنه:
• اول بفهمی طرف مقابل از چی میترسه یا نگران چیه (نه فقط چی میگه)
• به جای «تو اشتباه میکنی» بگی «من این نگرانی رو دارم که…»
• اگه بحث فنی قفل شد، یه نفر سوم بیطرف بیار وسط یا روی دیتا و تست تصمیم بگیرین
• گاهی وقتا کوتاه اومدن، قویتر بودنه؛ مخصوصاً وقتی موضوع حیاتی نیست
تعارض بد نیست.
تعارضی بد میشه که تبدیل به لجبازی شخصی بشه و تیم رو از هدف اصلیش دور کنه.
💬شما تو تیمتون معمولاً سر چی بیشتر به مشکل میخورین؟ معماری، کد ریویو، یا اولویتبندی
کارها؟
#برنامهنویسی #مدیریت_تعارض #SoftSkills #تیم_نرمافزاری #کدنویسی #آنوفل #Anophel | 75 |
| 8 | No text... | 1 |
| 9 | 💢 یادگیری 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 | 71 |
| 10 | 🐧 کدوم توزیع لینوکس برای چه کسی مناسبه؟
یکی از سوالهای همیشگی موقع مهاجرت به لینوکس:
«کدوم 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 | 66 |
| 11 | ⭐️چطور به ۵۰ میلیون کاربر نوتیفیکیشن بفرستیم؟
فرض کن یک اپلیکیشن داریم با ۵۰ میلیون کاربر فعال و میخواهیم وقتی اتفاق مهمی افتاد، به همهشان 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 | 48 |
| 12 | 🚨 یک اتفاق امنیتی مهم در دنیای 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 | 66 |
| 13 | 🧠 یه اشتباه رایج تو طراحی سیستمهای نوتیفیکیشن اینه که 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 | 89 |
| 14 | No text... | 1 |
| 15 | 😃یکی اومده کل استک یه دستیار هوش مصنوعی رو از صفر با 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 | 104 |
| 16 | 🍷برای اینکه مطمئن بشی VPN درست کار(نشتی ip نداره) میکنه، میتونی از سایت BrowserLeaks استفاده کنید. این سایت IP فعلی، موقعیت تقریبی، اطلاعات شبکه و همچنین تست DNS Leak و WebRTC Leak رو نشون میده تا مطمئن بشی #اطلاعات واقعی اینترنتت لو نمیره. اگر بعد از اتصال به VPN، آیپی و DNS نمایشدادهشده مربوط به سرور VPN باشه و نه اینترنت خودت، یعنی اتصال بهدرستی برقرار شده و نشتی وجود نداره.
این سایت ها #امنیت سرور و نشت در اپ ها رو نشون میده:
https://browserleaks.com/ip
https://myip.theazizi.ir/
@xsfilterrnet 👑
@xszapass 🤩 | 66 |
| 17 |  🐝 Hive v0.1.0 منتشر شد! 🚀
اولین نسخه عمومی Hive منتشر شد.
این نسخه یک MVP است؛ یعنی شروع مسیر، نه نسخه نهایی.
میدونیم هنوز:
🐛 باگهایی وجود داره
🔨 نیاز به Refactor و تمیزکاری کد داریم
📚 مستندات کامل آماده نیست
فعلاً توان خرید دامنهی .dev و راهاندازی سایت مستندات رو نداریم :(
پس فعلاً با GitHub و کانال کنار هم پیش میریم.
برای رشد Hive خوشحال میشیم کمک کنید:
💛 تست کنید
💛 باگ گزارش بدید
💛 در بهبود کد و Refactor کمک کنید
💛 و اگر دوست داشتید حمایت کنید ❤️
ما هم ادامه میدیم و نسخههای بعدی خیلی بهتر و خفنتر خواهند شد. 🚀
این تازه شروع Hive است 🐝
GitHub:
https://github.com/HiveSofts/hive-app
آموزشها و مستندات ویدیویی:
Instagram: @arshiamohammadei
Telegram: @aasshiaa
@TheRaymondDev | 70 |
| 18 |  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 | 76 |
| 19 | ✅یکی از کمبودهای قدیمی 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 | 882 |
| 20 | No text... | 0 |
