Anophel | آنوفل
Open in Telegram
آنوفل | Anophel: دنیای بی پایان امکانات برای برنامه نویسان https://anophel.com پشتیبانی : @anophel_support
Show moreThe country is not specifiedThe category is not specified
278
Subscribers
+224 hours
+507 days
+5030 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
July '26
July '26
+56
in 1 channels
June '26
+228
in 1 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 28 July | +1 | |||
| 27 July | +2 | |||
| 26 July | +4 | |||
| 25 July | +12 | |||
| 24 July | +32 | |||
| 23 July | 0 | |||
| 22 July | 0 | |||
| 21 July | +1 | |||
| 20 July | 0 | |||
| 19 July | 0 | |||
| 18 July | +1 | |||
| 17 July | 0 | |||
| 16 July | 0 | |||
| 15 July | 0 | |||
| 14 July | 0 | |||
| 13 July | 0 | |||
| 12 July | 0 | |||
| 11 July | 0 | |||
| 10 July | 0 | |||
| 09 July | 0 | |||
| 08 July | +1 | |||
| 07 July | 0 | |||
| 06 July | 0 | |||
| 05 July | 0 | |||
| 04 July | +1 | |||
| 03 July | +1 | |||
| 02 July | 0 | |||
| 01 July | 0 |
Channel Posts
🧠 یه اشتباه رایج تو طراحی سیستمهای نوتیفیکیشن اینه که 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
| 2 | No text... | 1 |
| 3 | 😃یکی اومده کل استک یه دستیار هوش مصنوعی رو از صفر با 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 | 34 |
| 4 | 🍷برای اینکه مطمئن بشی VPN درست کار(نشتی ip نداره) میکنه، میتونی از سایت BrowserLeaks استفاده کنید. این سایت IP فعلی، موقعیت تقریبی، اطلاعات شبکه و همچنین تست DNS Leak و WebRTC Leak رو نشون میده تا مطمئن بشی #اطلاعات واقعی اینترنتت لو نمیره. اگر بعد از اتصال به VPN، آیپی و DNS نمایشدادهشده مربوط به سرور VPN باشه و نه اینترنت خودت، یعنی اتصال بهدرستی برقرار شده و نشتی وجود نداره.
این سایت ها #امنیت سرور و نشت در اپ ها رو نشون میده:
https://browserleaks.com/ip
https://myip.theazizi.ir/
@xsfilterrnet 👑
@xszapass 🤩 | 35 |
| 5 |  🐝 Hive v0.1.0 منتشر شد! 🚀
اولین نسخه عمومی Hive منتشر شد.
این نسخه یک MVP است؛ یعنی شروع مسیر، نه نسخه نهایی.
میدونیم هنوز:
🐛 باگهایی وجود داره
🔨 نیاز به Refactor و تمیزکاری کد داریم
📚 مستندات کامل آماده نیست
فعلاً توان خرید دامنهی .dev و راهاندازی سایت مستندات رو نداریم :(
پس فعلاً با GitHub و کانال کنار هم پیش میریم.
برای رشد Hive خوشحال میشیم کمک کنید:
💛 تست کنید
💛 باگ گزارش بدید
💛 در بهبود کد و Refactor کمک کنید
💛 و اگر دوست داشتید حمایت کنید ❤️
ما هم ادامه میدیم و نسخههای بعدی خیلی بهتر و خفنتر خواهند شد. 🚀
این تازه شروع Hive است 🐝
GitHub:
https://github.com/HiveSofts/hive-app
آموزشها و مستندات ویدیویی:
Instagram: @arshiamohammadei
Telegram: @aasshiaa
@TheRaymondDev | 42 |
| 6 |  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 | 48 |
| 7 | ✅یکی از کمبودهای قدیمی 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 | 653 |
| 8 | No text... | 0 |
| 9 | No text... | 0 |
| 10 | 💡یک نکته مهم درباره 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 | 176 |
| 11 | ❓اگر قرار باشد کاربران را بر اساس وضعیت فیلتر کنید، کدام طراحی بهتر است؟
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 | 167 |
| 12 | 🔥کارت گرفیک 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 | 134 |
| 13 | 🔥 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 @anophel | 1 |
| 14 | https://t.me/boost/anophel | 95 |
| 15 | 🚀 «هوش مصنوعی (AI) اومده، پس دیگه لازم نیست Hard Skill یاد بگیریم؟»
این یکی از بزرگترین سوءبرداشتهای این روزهاست.
هوش مصنوعی جای یادگیری رو نگرفته؛ فقط سرعت انجام کارها رو بیشتر کرده.
اگر مفاهیم پایه (Fundamentals)، معماری نرمافزار (Software Architecture)، الگوریتمها (Algorithms)، دیباگ (Debugging)، امنیت (Security) یا طراحی سیستم (System Design) رو بلد نباشی، حتی خروجی AI رو هم نمیتونی درست ارزیابی کنی. در بهترین حالت فقط کسی هستی که کد تولیدشده توسط AI رو بدون درک واقعی استفاده میکنه.
اما چیزی که امروز بیشتر از قبل اهمیت پیدا کرده، ترکیب Hard Skill و Soft Skill هست.
🔹 Hard Skill باعث میشه مسئله رو عمیق بفهمی و راهحل درست ارائه بدی.
🔹 Soft Skill باعث میشه بتونی با تیم ارتباط مؤثر برقرار کنی، ایدههات رو منتقل کنی و تأثیرگذار باشی.
و یک تفاوت مهم…
کسانی که فقط برای «داشتن شغل» وارد دنیای Tech شدن، با پیشرفت AI بیشتر تحت فشار قرار میگیرن. اما افرادی که با کنجکاوی، علاقه و اشتیاق وارد این حوزه شدن، از AI بهعنوان یک ابزار برای قویتر شدن استفاده میکنن، نه یک رقیب.
آینده متعلق به کسانی نیست که از AI میترسن؛
بلکه متعلق به کسانیه که دانش عمیق رو با ابزارهای هوشمند ترکیب میکنن.
💬هوش مصنوعی (AI) جای متخصصها را نمیگیرد؛ متخصصهایی که از AI استفاده میکنند، جای بقیه را میگیرند.
—
#AI #Programming #SoftwareEngineering #HardSkills #SoftSkills #Coding #Developers #Tech #Anophel | 100 |
| 16 | هرمس Hermes چیست و چرا اینقدر دربارهاش صحبت میشود؟ 🤖
اگر چند وقت اخیر در حوزه AI بوده باشید، احتمالاً اسم Hermes را کنار مدلهایی مثل Llama، Qwen یا Mistral دیدهاید.
اما یک نکته مهم وجود دارد که خیلیها از آن خبر ندارند:
هرمس Hermes یک مدل پایه (Foundation Model) نیست.
پس چیست؟
فرض کنید یک مدل قدرتمند مثل Llama از قبل وجود دارد؛ مدلی که میلیاردها پارامتر دارد و روی حجم عظیمی از دادهها آموزش دیده است.
حالا تیم Nous Research همان مدل را دوباره با دادههای باکیفیت، مکالمات واقعی، نمونههای برنامهنویسی و دستورهای مختلف آموزش میدهد تا:
بهتر با انسان گفتگو کند.
دستورات را دقیقتر اجرا کند.
در برنامهنویسی عملکرد بهتری داشته باشد.
استدلال منطقیتری انجام دهد.
برای ساخت AI Agentها آمادهتر باشد.
به این فرآیند میگویند Instruction Tuning و نتیجه آن میشود Hermes.
⸻
🔵یک مثال ساده
فرض کنید دو نفر را داریم:
👨🎓 نفر اول، تازه از دانشگاه فارغالتحصیل شده و دانش زیادی دارد.
👨💼 نفر دوم، همان فرد است؛ اما چند سال هم در یک شرکت بزرگ کار کرده و یاد گرفته چطور با مشتری صحبت کند، مسئله حل کند و پروژه تحویل دهد.
دانش هر دو تقریباً یکی است، اما نفر دوم در دنیای واقعی عملکرد بهتری دارد.
هرمس Hermes دقیقاً همین نقش را برای مدلهای زبانی بازی میکند.
⸻
تفاوت اصطلاحاتی که همیشه میبینید
🔹Base Model
مدلی که از صفر آموزش دیده است.
مثال:
Llama
Qwen
Mistral
⸻
🔹Instruction Model
همان Base Model که برای گفتگو و اجرای دستورات بهینه شده است.
مثال:
Hermes
نسخههای Instruct
نسخههای Chat
⸻
🔹Reasoning Model
مدلی که برای حل مسائل چندمرحلهای، تحلیل و استدلال بهینه شده است.
⸻
💠چرا Hermes محبوب شده؟
چون بدون اینکه هزینه آموزش یک مدل جدید را داشته باشد، تجربه کار با مدل را به شکل محسوسی بهتر میکند.
به همین دلیل بسیاری از پروژههای متنباز، AI Agentها و حتی ابزارهای برنامهنویسی از نسخههای Hermes استفاده میکنند.
⸻
اگر فقط یک نکته را از این پست به خاطر بسپارید:
❌هرمس Hermes رقیب Llama نیست.
✅ هرمس Hermes نسخهای بهینهشده از مدلهایی مثل Llama، Qwen یا Mistral است که برای تعامل بهتر با انسان آموزش دیدهاند.
همین تفاوت کوچک، یکی از مهمترین مفاهیمی است که برای درک اکوسیستم LLMها باید بدانید.
#AI #LLM #Hermes #Llama #Qwen #Mistral #OpenSource #Programming #Anophel | 86 |
| 17 |  🔐 بهترین روش احراز هویت در سال ۲۰۲۶؛ Session یا JWT؟
یکی از پرتکرارترین سؤالهایی که بین برنامهنویسها وجود داره اینه:
Session؟ JWT؟ Cookie؟ یا ترکیبشون؟
واقعیت اینه که JWT بهتنهایی یک مکانیزم احراز هویت نیست؛ فقط یک فرمت برای Token هست. چیزی که باید انتخاب کنید، معماری احراز هویته، نه صرفاً نوع توکن.
⸻
🟢 Session
در این روش، اطلاعات نشست کاربر روی سرور ذخیره میشه و مرورگر فقط یک Session Cookie نگه میداره.
✅ مزایا:
امنیت بالا
Logout واقعی (با حذف Session)
Revocation ساده
مناسب برای وباپلیکیشنهای سنتی
❌معایب:
نیاز به Session Store (مثل Redis)
کاملاً Stateless نیست.
⸻
🔵JWT
در JWT اطلاعات داخل خود Token قرار میگیره و سرور معمولاً نیازی به نگهداری Session نداره.
✅مزایا:
Stateless
مقیاسپذیری بالا
مناسب برای Microserviceها
❌معایب:
Logout سختتر
Revocation پیچیدهتر
اگر Token سرقت بشه، تا زمان انقضا معتبر باقی میمونه.
⸻
🚀 معماری پیشنهادی برای پروژههای مدرن
امروزه اکثر سیستمهای مدرن از این معماری استفاده میکنند:
🔹 Access Token کوتاهعمر (۵ تا ۱۵ دقیقه)
🔹 Refresh Token بلندمدت
🔹 هر دو داخل HttpOnly + Secure Cookie
🔹 ذخیره Refresh Token در Redis یا Database
🔹 Refresh Token Rotation برای افزایش امنیت
این روش هم مقیاسپذیره و هم امکان Logout و Revocation واقعی رو فراهم میکنه.
⸻
❌Bad Practices
از این اشتباهات تا حد امکان دوری کنید:
نگهداری JWT داخل LocalStorage یا SessionStorage
Access Token با عمر خیلی طولانی
استفاده نکردن از HTTPS
تنظیم نکردن HttpOnly و Secure روی Cookie
ذخیره اطلاعات حساس داخل JWT
نداشتن مکانیزم Refresh Token Rotation
اعتماد به دادههای داخل JWT بدون اعتبارسنجی امضا (Signature)
⸻
⬜️ توصیههای OWASP
اگر امنیت براتون مهمه، این موارد رو رعایت کنید:
✔️ Access Token کوتاهعمر
✔️ HttpOnly Cookie
✔️ Secure Cookie
✔️ SameSite=Lax یا Strict
✔️ HTTPS اجباری
✔️ Refresh Token Rotation
✔️ اعتبارسنجی کامل Signature و Claims
✔️ عدم قرار دادن اطلاعات حساس داخل Token
⸻
🔵جمعبندی:
برای وباپلیکیشنهای سنتی، Session + Cookie هنوز هم یکی از بهترین و امنترین انتخابهاست.
برای APIها، SPAها و معماریهای مدرن، JWT + HttpOnly Cookie + Refresh Token Rotation بهترین تعادل بین امنیت، مقیاسپذیری و تجربه کاربری رو ارائه میده.
امنیت یک قابلیت نیست؛ یک فرایند مداومه.
—
💙 @anophel
جایی برای یادگیری عمیق برنامهنویسی، امنیت و معماری نرمافزار. | 57 |
| 18 | Harness چیست؟ واژهای که این روزها زیاد در دنیای AI میشنوید
اگر مدتی در حوزه AI و Agentها بوده باشید، احتمالاً چند بار کلمه Harness به گوشتان خورده است. اما Harness دقیقاً چیست؟
به زبان ساده:
Harness لایهای است که مدل هوش مصنوعی را کنترل و مدیریت میکند.
خیلیها فکر میکنند قدرت یک Agent فقط به مدلش بستگی دارد؛ اما در عمل، مدل فقط بخشی از ماجراست.
فرض کنید از GPT، Claude یا Gemini استفاده میکنید. خود مدل فقط متن تولید میکند. این Harness است که تصمیم میگیرد:
• چه فایلهایی خوانده شوند • چه ابزارهایی فراخوانی شوند • چه Contextی به مدل داده شود • خطاها چگونه مدیریت شوند • چند بار عملیات Retry شود • مدل به چه منابعی دسترسی داشته باشد
در واقع چیزی که ما به عنوان یک «Agent هوشمند» میبینیم، معمولاً ترکیبی از این دو بخش است:
LLM + Harness = Agent
به همین دلیل ممکن است دو محصول از دقیقاً یک مدل استفاده کنند، اما یکی خروجی بسیار بهتری داشته باشد؛ چون Harness بهتری طراحی کرده است.
⸻
Eval Harness چیست؟
نوع دیگری از Harness که زیاد شنیده میشود، Eval Harness است.
اگر در Go از go test استفاده کرده باشید، درک آن ساده است.
Eval Harness مجموعهای از سناریوها و تستها را روی مدل اجرا میکند تا مشخص شود عملکرد آن چقدر خوب است.
مثلاً:
100 Question
↓
Run Model
↓
Measure Accuracy
↓
Compare Results
با این کار میتوان فهمید تغییر یک Prompt، ابزار جدید یا حتی تعویض مدل واقعاً باعث بهبود شده یا نه.
⸻
نکته جالب
در بسیاری از Agentهای مدرن، کیفیت نهایی محصول بیشتر از اینکه به خود مدل وابسته باشد، به Harness وابسته است.
به همین خاطر این روزها در کنار نام مدلها، عبارتهایی مثل:
• Agent Harness • Coding Harness • Eval Harness
را زیاد میبینید.
در یک جمله:
Harness همان Runtime یا Orchestration Layer دنیای LLMهاست؛ بخشی که مدل را به یک سیستم کاربردی واقعی تبدیل میکند.
#AI #LLM #Agent #GPT #Claude #MachineLearning #Programming #Anophel | 62 |
| 19 | 📝 TODOها برای انجام شدن نیستند!
خیلی از تیمها با TODOها مثل تسکهای ناقص رفتار میکنند؛ یا باید وارد Jira شوند، یا بعد از مدتی از کد حذف شوند.
اما شاید این نگاه اشتباه باشد.
وقتی این را میبینیم:
// TODO: Finish implementing the payment retry mechanism before launch
واضح است که یک کار ناتمام وجود دارد و باید روزی انجام شود.
اما همه TODOها این شکلی نیستند.
گاهی TODO بیشتر شبیه این است:
// TODO: Triple-clicking this button causes the handler to panic because state can become nil
آیا این مهمترین آیتم بکلاگ است؟ احتمالاً نه. آیا بیشتر کاربران هرگز با آن مواجه میشوند؟ احتمالاً نه.
اما این کامنت یک چیز ارزشمند را حفظ کرده است: دانش نویسندهٔ کد.
یک TODO خوب میتواند توضیح دهد که: • چه edge caseهایی هنوز پوشش داده نشدهاند. • چه محدودیتهایی در طراحی فعلی وجود دارد. • چه ایدهای برای بهبود وجود داشته اما زمان پیادهسازیاش نبوده است. • یا حتی چرا کد عمداً به این شکل نوشته شده است.
بارها پیش آمده که هنگام خواندن کد با خودمان گفتهایم:
«نکنه چیزی را نمیفهمم؟ شاید این قسمت را میشد خیلی بهتر نوشت…»
و بعد یک TODO دقیق، همان سؤالی را که در ذهنمان بوده پاسخ داده است.
TODOها همیشه قرار نیست به یک تسک تبدیل شوند. گاهی فقط پنجرهای کوچک به ذهن کسی هستند که ماهها یا سالها قبل این کد را نوشته است.
و این نوع دانش، اغلب از خود کد ارزشمندتر است.
#Programming #SoftwareEngineering #CleanCode #CodeReview #DeveloperTips #Anophel | 80 |
| 20 | 🚀 Idempotency؛ ناجی سیستمهای توزیعشده
تصور کنید کاربر روی دکمه «پرداخت» کلیک میکند، اما به خاطر کندی اینترنت فکر میکند درخواست ارسال نشده و دوباره روی آن کلیک میکند.
حالا چه اتفاقی میافتد؟
❌ اگر سیستم شما Idempotent نباشد:
ممکن است پرداخت چند بار انجام شود.
چند سفارش یکسان ثبت شود.
چند ایمیل یا پیامک تکراری ارسال شود.
✅ اما با Idempotency:
درخواست اول پردازش میشود.
درخواستهای تکراری شناسایی میشوند.
نتیجه نهایی فقط یک بار اعمال میشود.
به بیان ساده:
اگر یک عملیات را ۱ بار یا ۱۰۰ بار اجرا کنید و نتیجه نهایی تغییری نکند، آن عملیات Idempotent است.
معمولاً برای پیادهسازی این مفهوم از Idempotency Key استفاده میشود؛ یک شناسه یکتا که همراه درخواست ارسال میشود تا سرور بتواند درخواستهای تکراری را تشخیص دهد.
💡 Idempotency یکی از آن مفاهیمی است که تا زمانی که با پرداختهای تکراری، سفارشهای چندباره یا Retryهای شبکه روبهرو نشوید، اهمیتش را درک نمیکنید.
#Programming #Backend #API #Microservices #DistributedSystems #SoftwareEngineering #Anophel | 71 |
