☑️ اختيار قاعدة البيانات المناسب لمشروعك

اختيار قاعدة البيانات قرار مصيري في أي مشروع، لأنه يؤثر على الأداء، التوسع، التكلفة، وسهولة التطوير.
قبل أن تختار، اسأل نفسك الأسئلة التالية 👇

1️⃣ ما طبيعة البيانات؟

بيانات منظمة (جداول، علاقات واضحة)
➜ قواعد بيانات علائقية Relational DB
مثل:
SQL Server – PostgreSQL – MySQL

بيانات غير منظمة أو مرنة (JSON, Logs, Documents)
➜ قواعد بيانات NoSQL
مثل:
MongoDB

2️⃣ ما حجم البيانات وسرعة النمو؟

حجم متوسط ونمو متوقع
➜ Relational DB كافية 👍

بيانات ضخمة جدًا وتنمو بسرعة
➜ NoSQL أو Distributed Databases
مثل:
Cassandra – DynamoDB

3️⃣ هل تحتاج معاملات دقيقة (Transactions)؟

* إذا كان المشروع يتطلب:

* تحويلات مالية
* حجوزات
* أنظمة محاسبية

➜ اختر قاعدة تدعم ACID بشكل قوي
✅ Relational DB هي الخيار الأفضل

4️⃣ هل الأداء أهم أم الاتساق؟

اتساق عالي (Consistency)
➜ Relational DB

أداء عالي وتوفر دائم (Availability & Scalability)
➜ NoSQL


5️⃣ فريقك وخبرته؟

* فريق معتاد على SQL؟
➜ Relational DB = إنتاجية أعلى

* فريق Backend حديث ويتعامل مع JSON؟
➜ NoSQL قد يكون أسهل

6️⃣ مثال عملي سريع

🔹 متجر إلكتروني

* الطلبات والدفع ➜ SQL Server / PostgreSQL
* سجل التصفح والـ Logs ➜ MongoDB

🔹 تطبيق تواصل اجتماعي

* المستخدمون والعلاقات ➜ Relational
* المنشورات والتفاعلات ➜ NoSQL

✨ الخلاصة

لا توجد قاعدة بيانات “أفضل مطلقًا”،
بل قاعدة بيانات مناسبة لحالة استخدامك.

📌 في المشاريع الكبيرة:

* استخدام أكثر من نوع قاعدة بيانات أصبح أمرًا طبيعيًا (Polyglot Persistence)

#من_فكرة_إلى_تطبيق #قاعدة_البيانات #Database #SQL #NoSQL #DataManagement #تحليل_البيانات #تطوير_برمجيات #برمجة #BigData #DataModeling #اختيار_قاعدة_البيانات #TechTips #DatabaseDesign #DataStrategy

🏷 اختر أسماء صحيحة وواضحة للجداول والأعمدة

اختيار أسماء مناسبة للجداول والأعمدة في قاعدة البيانات ليس مجرد مسألة شكلية، بل له تأثير كبير على قابلية صيانة قاعدة البيانات، وضوح الكود، وتقليل الأخطاء عند التطوير.

1️⃣ القواعد الأساسية لأسماء الجداول:

* استخدم أسماء مفهومة وواضحة: اجعل الاسم يعكس محتوى الجدول.

* مثال: Users بدلًا من Tbl1
* استخدم صيغة المفرد أو الجمع بحذر: غالبًا يفضل صيغة الجمع (Users, Orders) لأنها تمثيل مجموع البيانات. بعض الفرق تفضل المفرد (User, Order) لتمثل كل سجل على حدة.
* تجنب المسافات والرموز الخاصة: استخدم _ للفصل إذا لزم الأمر.

* مثال: order_items وليس order items.
* حافظ على الاتساق: اختر نمطًا وطبق على كل الجداول (CamelCase, snake_case…).

2️⃣ القواعد الأساسية لأسماء الأعمدة:

* اختر أسماء واضحة ودقيقة: الاسم يجب أن يصف نوع البيانات المخزنة.

* مثال: first_name`، `created_at.
* تجنب الاختصارات الغامضة: مثل fn أو `crdt`، إلا إذا كانت معروفة للفريق.
* أضف سياق عند الحاجة: خاصة عند وجود أعمدة متشابهة بين جداول مختلفة.

* مثال: user_id في جدول Orders يوضح أنه يشير لمعرف المستخدم.
* توحيد النمط: استخدم نفس نمط التسمية في كل الأعمدة (CamelCase, snake_case, PascalCase…).

3️⃣ قواعد عامة:

* تجنب الكلمات المحجوزة Reserved Words: مثل Date, User في بعض قواعد البيانات.
* كن متسقًا: أفضل قاعدة هو اختيار نمط معين (مثلاً snake_case لكل شيء) وعدم المزج بين أنماط مختلفة.
* أسماء قصيرة لكنها وصفية: تجنب الأسماء الطويلة جدًا أو القصيرة جدًا.


✅ نصيحة مهمة: قبل البدء بالمشروع، ضع قائمة Naming Conventions ثابتة للفريق لتجنب الالتباس لاحقًا، خصوصًا عند العمل في فرق كبيرة أو مشاريع طويلة المدى.

#من_فكرة_إلى_تطبيق #قاعدة_البيانات #Database #SQL #NoSQL #DataManagement #تحليل_البيانات #تطوير_برمجيات #برمجة #BigData #DataModeling #اختيار_قاعدة_البيانات #TechTips #DatabaseDesign #DataStrategy

⚠️ القيمة NULL: الصديق الغامض والمخرب الخفي!

القيمة NULL ليست رقماً، وليست نصاً فارغاً '' ، وليست صفراً.
هي تعني ببساطة: قيمة مفقودة أو غير معروفة.

إليك طريقة التعامل معها باحترافية:

1️⃣ قاعدة المنطق الثلاثي (Three-Valued Logic):
في قواعد البيانات، النتيجة ليست دائماً (صح أو خطأ) هناك حالة ثالثة هي أن تكون القيمة غير معرفة.

❌ WHERE salary = NULL (لن تعيد أي نتيجة أبداً!)
✅ WHERE salary IS NULL

2️⃣ احذر "العدوى الصفْرية" في الحسابات:
أي عملية حسابية يدخل فيها NULL، تحول النتيجة فوراً إلى NULL.
1000 + NULL = NULL
استخدم COALESCE لتجنب انهيار معادلاتك:
SELECT COALESCE(bonus, 0) + salary FROM employees;

3️⃣ التصميم الذكي (Schema Design):

* لا تسمح بـ NULL إلا إذا كان غياب المعلومة له معنى منطقي.
* استخدم NOT NULL مع DEFAULT (مثل 0 للأرقام أو '' للنصوص) لتبسيط الاستعلامات لاحقاً.

4️⃣ الفهارس (Indexes) والأداء:
تذكر أن بعض المحركات (مثل Oracle) لا تخزن قيم NULL في الفهارس التقليدية (B-Tree)، مما قد يجعل استعلامات IS NULL بطيئة جداً في الجداول الضخمة.

5️⃣ الدوال المنقذة:

* COALESCE(val1, val2, ...) : تعيد أول قيمة غير فارغة.
* NULLIF(val1, val2) : تعيد NULL إذا تساوت القيمتان .

مشكلة شائعة
SELECT salary / bonus FROM employees;
إذا كان bonus = 0 → سيحدث خطأ.

الحل باستخدام NULLIF
SELECT salary / NULLIF(bonus, 0) FROM employees;
ماذا يحدث هنا؟

إذا كان bonus = 0
→ NULLIF(bonus, 0) تُرجع NULL
القسمة تصبح:
salary / NULL
النتيجة NULL بدل حدوث خطأ ❌
إذا كان bonus ≠ 0
تُرجع قيمة bonus الطبيعية

💡 الخلاصة:
قاعدة البيانات القوية هي التي تتوقع "فقدان البيانات" وتضع له سيناريو مسبق. لا تترك NULL للصدفة!

#SQL #Databases #NULLIF #COALESCE #BackendDevelopment #قواعد_البيانات #برمجة #هندسة_البرمجيات #SQLTips

🗑 الـ Soft Delete والـ Hard Delete

أثناء تصميم قاعدة البيانات، قرار الحذف ليس بسيطًا كما يبدو 👀
هل تحذف البيانات نهائيًا؟ أم تكتفي بإخفائها؟
الاختيار الخاطئ قد يسبب فقدان بيانات مهمة أو مشاكل أداء مستقبلية.

🔹 Soft Delete (الحذف المنطقي)
يعني الإبقاء على السجل داخل قاعدة البيانات مع وضع علامة تشير إلى أنه محذوف.

📌 غالبًا يتم عبر:
is_deleted
deleted_at

✅ متى يكون الخيار الأفضل؟

* إذا كنت تحتاج إمكانية الاسترجاع لاحقًا
* في الأنظمة التي تتطلب تتبع العمليات (Audit / Logs)
* لتقليل مخاطر الحذف الخاطئ
* في الأنظمة المالية والإدارية

⚠️ انتبه لهذه النقاط:

* كل استعلام يجب أن يستثني السجلات المحذوفة
* مشاكل مع Unique Constraints (مثل البريد الإلكتروني)
* تضخم حجم الجداول والـ Index مع الوقت

🔹 Hard Delete (الحذف النهائي)
حذف السجل بالكامل من قاعدة البيانات باستخدام DELETE.

✅ متى نستخدمه؟

* للبيانات المؤقتة (Sessions، OTP، Logs)
* عند الالتزام بقوانين الخصوصية مثل GDPR (حق النسيان)
* لتحسين الأداء في الجداول الكبيرة

⚠️ عيوبه:

* لا يمكن استرجاع البيانات بعد الحذف
* قد يسبب مشاكل في العلاقات (Foreign Keys) إن لم يُستخدم بحذر


💡 أفضل الممارسات:
1️⃣ استخدم Soft Delete للبيانات الأساسية (Users، Orders، Invoices)
2️⃣ استخدم Hard Delete للبيانات المؤقتة وغير المهمة
3️⃣ لا تترك البيانات المحذوفة تتراكم — فعّل الأرشفة
4️⃣ حل مشكلة الـ Unique عبر تصميم ذكي للمفاتيح

📌 الخلاصة:
لا يوجد خيار «صحيح دائمًا»
القرار يعتمد على طبيعة البيانات، المتطلبات القانونية، والأداء.

#قواعد_البيانات #تصميم_الأنظمة #هندسة_البرمجيات #تطوير_البرمجيات #حماية_البيانات #الخصوصية #GDPR
#Database #SoftDelete #HardDelete #Backend #SoftwareEngineering #SystemDesign #DataPrivacy #GDPR

📊 الـ Normalization والـ Denormalization: متى ولماذا؟

أثناء تصميم قاعدة البيانات، يواجه كل مطور هذا السؤال الجوهري 👇
هل أطبّق الـ Normalization أم ألجأ للـ Denormalization؟

هذا القرار ليس مجرد تفصيل تقني، بل هو ميزان يؤثر مباشرة على الأداء، سهولة الصيانة، وتكامل البيانات ⚖️


🧩 أولًا: الـ Normalization (التطبيع)
المفهوم: تقسيم البيانات إلى جداول متعددة لتقليل التكرار والاعتماد على العلاقات (Relationships).
*💡 مثال: فصل "بيانات العميل" في جدول، و"الطلبات" في جدول آخر.*

✅ متى نستخدمه؟

* عند بناء النظام من الصفر (The Standard Start).
* عندما تكون العمليات مكثفة على التحديث والإضافة (Write-heavy).
* إذا كانت سلامة البيانات (Data Integrity) هي الأولوية القصوى.

🌟 المميزات: تقليل المساحة، منع تناقض البيانات، وسهولة التعديل في مكان واحد.
⚠️ العيوب: كثرة الـ JOIN مما قد يجعل الاستعلامات المعقدة أبطأ قليلاً.


⚡️ ثانيًا: الـ Denormalization (إلغاء التطبيع)
المفهوم: دمج البيانات أو إضافة تكرار "مقصود" في جداول أقل لتقليل العمليات الحسابية وقت القراءة.
*💡 مثال: وضع "اسم العميل" داخل جدول "الطلبات" مباشرة لتجنب الـ JOIN عند عرض الفاتورة.*

✅ متى نستخدمه؟

* في الأنظمة التي تعتمد على القراءة المكثفة (Read-heavy).
* في لوحات التحكم (Dashboards) والتقارير والـ Analytics.
* عندما يصبح زمن الاستجابة (Latency) عائقاً أمام تجربة المستخدم.

🌟 المميزات: سرعة استثنائية في جلب البيانات، وتبسيط استعلامات الـ SQL.
⚠️ العيوب: خطر "عدم تطابق البيانات"، زيادة مساحة التخزين، وصعوبة تحديث البيانات المكررة.


🎯 الخلاصة المعمارية:
1️⃣ ابدأ دائمًا بـ Normalization كقاعدة أساسية.
2️⃣ لا تكسر القواعد وتستخدم Denormalization إلا لسبب واضح (Performance Bottleneck).
3️⃣ لا يوجد حل مثالي لكل الحالات.. السياق هو الحكم 👌

💡 تذكر: أفضل الأنظمة هي التي توازن بينهما؛ هيكل منظم للبيانات الأساسية، وجداول "مفلطحة" (Flat Tables) للتقارير السريعة.


💬
هل اضطررت لكسر قواعد الـ Normalization في مشروعك لتحسين الأداء؟ وما هي المشكلة التي واجهتك؟ شاركنا تجربتك في التعليقات! 👇

#Database #SQL #Backend #SystemDesign #Normalization #قواعد_البيانات #برمجة #هندسة_البرمجيات

انتبهوا يامبرمجين مبرمج صيني مات من كثر الشغل 💀

بعد ما ترقى وعمره 32، صار دايم يتأخر بعد الدوام، وحتى يشتغل ويقفل تاسكات بالويكند. وتخيلوا حتى يوم دخل المستشفى… زملاؤه ضافوه على شات شغل جديد 🤦‍♂️

تذكروا هالقصة يوم تفكرون تقولون: “يلا بس ساعة زيادة”

🗄 سلسلة تصميم قاعدة البيانات في
Track Cash (1/5)

هل فكرت يومًا…
كيف يدير تطبيق مالي مئات العمليات، الميزانيات، المحافظ، وحتى المرفقات؟ 🤔
السر كله يبدأ من قاعدة البيانات — العقل الذي يشغّل كل شيء.
واليوم نبدأ أول جزء من تصميم قاعدة البيانات في تطبيق Track Cash ✨
تابع معنا خطوة بخطوة 👇

👤 People – الأشخاص
هو الجذر الأساسي لكل الهويات في النظام، ويسجل:
الاسم والبيانات المشتركة بين المستخدمين وسواء كان مستخدم عادي أو إداري
تاريخ الإنشاء

🧩 لماذا نستخدم جدول الأشخاص؟
لأنه يفصل هوية الشخص الأساسية عن أي دور يؤديه داخل التطبيق.
فالشخص نفسه قد يكون:
مستخدمًا عاديًا
أو مديرًا
أو قد يكتسب أدوارًا أخرى مستقبلًا
هذا الفصل يجعل التوسع والتطوير أسهل بدون تعديل الجداول الأساسية كل مرة.

👥 Users – المستخدمون
يرتبط بجدول People، ويحتوي:
الإيميل
كلمة المرور المشفرة
العملة المفضلة
اللغة
وهو الحساب الأساسي للمستخدم داخل التطبيق.

🛡 Admins – المدراء
مرتبط أيضًا بـ People، لكنه مخصص للمدراء ويمنحهم صلاحيات خاصة لإدارة النظام وصيانته.

⚙️ User Settings – إعدادات المستخدم
يخزن إعدادات المستخدم بصيغة JSONB مثل:

الوضع الليلي
التنبيهات
شكل الواجهة

الميزة؟
يمكن إضافة إعدادات جديدة مستقبلًا بدون تعديل بنية الجدول!

📍 تابعونا في الجزء القادم…
سنتعرف على الجداول المالية الأساسية التي تشغّل Track Cash 🚀

#من_فكرة_إلى_تطبيق #TrackCash #قواعد_البيانات

🗄️ سلسلة تصميم قاعدة البيانات في 
               Track Cash (2/5)

المحافظ والعمليات — قلب النظام المالي 💰⚡
في هذا الجزء نغوص مباشرة في اللبّ الحقيقي لأي تطبيق مالي:
أين تُخزَّن أموالك؟ وكيف تُسجَّل عمليات الصرف والدخل؟

هنا يبدأ Track Cash في بناء الصورة المالية الكاملة للمستخدم.

🏦 1) Accounts – الحسابات (المحافظ)
المحافظ هي أول ما يضيفه المستخدم داخل التطبيق، وتمثّل مصادر أمواله، مثل:

محفظة نقدية
حساب بنكي
بطاقة مسبقة الدفع
محفظة إلكترونية

ويحتوي كل حساب على:

اسم الحساب
الرصيد الحالي
نوع الحساب
العملة
تاريخ الإنشاء

لماذا المحافظ مهمة؟
لأن كل عملية مالية يجب أن ترتبط بمحفظة معيّنة … مما يسمح بحساب الرصيد بدقة وعرض تقارير حسب كل حساب على حدة.

💸 2) Transactions – العمليات المالية
الجدول الأكثر أهمية في النظام.
كل حركة مالية — مهما كانت — تسجَّل هنا.
وتشمل العملية:

نوع العملية (دخل / مصروف / تحويل من محفظة لاخرى)
المبلغ
الحساب المرتبط (المحفظة)
التاريخ
الملاحظات
المرفقات (صور الفواتير أو الإيصالات)

هذا الجدول هو المحور الذي يُبنى عليه:

الرصيد الفعلي للمحافظ
تقارير المصروفات
إحصائيات الدخل
الرسوم البيانية
التنبيهات المالية

بدونه… لا توجد أي ميزة تحليلية داخل Track Cash.

📊 خلاصة الجزء الثاني
المحافظ + العمليات = الأساس الحقيقي لإدارة المال داخل التطبيق.
منهما يبدأ كل شيء: تسجيل، تحليل، تتبع، وإحصاءات دقيقة.

📍 في الجزء الثالث…
سنتعرف على التصنيفات والميزانيات وكيف تساعد Track Cash في تنظيم المصاريف وتقديم تنبيهات ذكية قبل تجاوز الميزانية 🚀✨

#من_فكرة_إلى_تطبيق #TrackCash #قواعد_البيانات

🎓 تنويه مهم لأصدقائنا في رحلة "من فكرة إلى تطبيق"
بعضكم راسلنا وقال إنه عنده ضعف بسيط في قواعد البيانات… وهذا شيء طبيعي جدًا!
وحتى نضمن إن كل متابع معنا ماشي بثقة وثبات 🚀

📌 قررنا نبدأ سلسلة من منشورات قصيرة وممتعة من الدروس المبسّطة في قواعد البيانات
دروس خفيفة، متدرجة، وبأسلوب عملي…
من الصفر إلى أنك تفهم كيف تبني قاعدة بيانات قوية لتطبيقك 💪🗄️

وبعد ما نتأكد إن الصورة وضحت للجميع…
✨ نكمل رحلتنا في تطوير التطبيق بإذن الله.

الجايات أجمل!
#من_فكرة_إلى_تطبيق #تطوير_تطبيقات #قواعد_البيانات #برمجة #ريادة_الأعمال

📌 مقارنة شاملة بين قواعد البيانات SQL و NoSQL
إذا كنت تبني تطبيقًا — مهما كان حجمه — فاختيار نوع قاعدة البيانات خطوة مصيرية تحدد أداء مشروعك وقدرته على التوسع 🚀.

الفرق بطريقة بسيطة وواضحة:

1️⃣ النموذج الأساسي (Data Model)
🔷 SQL – قواعد بيانات علائقية
تعتمد على الجداول والعلاقات.
تحتاج مخطط ثابت (Schema).
تمنع تكرار البيانات من خلال المفاتيح.
🔶 NoSQL – غير علائقية
أنواع متعددة تناسب سيناريوهات مختلفة:
Document مثل: MongoDB
Key-Value مثل: Redis
Graph مثل: Neo4j
Wide-Column مثل: Cassandra
مرنة وما تحتاج مخطط ثابت.

2️⃣ لغة الاستعلامات
🔹 SQL: لغة موحدة وقوية للتعامل مع البيانات.
🔸 NoSQL: كل نظام له أسلوبه… ما في معيار واحد للجميع.


3️⃣ قابلية التوسع (Scalability)
⬆️ SQL: توسع عمودي (تقوية السيرفر).
↔️ NoSQL: توسع أفقي بسهولة (إضافة سيرفرات جديدة).

4️⃣ أفضل حالات الاستخدام
🎯 متى تستخدم SQL؟
بيانات منظمة وعلاقات معقدة.
تحتاج اتساق عالي (مثال: أنظمة البنوك).
الهيكل ثابت وواضح.
🚀 متى تستخدم NoSQL؟
بيانات ضخمة ومتغيرة باستمرار.
تطبيقات تحتاج توسع وأداء عالي.
أنظمة ويب وموبايل عالية التوفر.

5️⃣ أمثلة على قواعد البيانات
💠 SQL:
PostgreSQL – MySQL – Oracle - SQL Server
💠 NoSQL:
MongoDB – Redis – Cassandra – Neo4j
🔥 الخلاصة: ليس تنافساً… بل تكامل!
اليوم أغلب التطبيقات الحديثة تستخدم أكثر من نوع قاعدة بيانات (Polyglot Persistence).
مثال عملي:
PostgreSQL → للمعاملات
Redis → للتخزين المؤقت
MongoDB → للمحتوى
Neo4j → لتحليل العلاقات

💡 القاعدة الذهبية:
اختر قاعدة البيانات التي تخدم احتياجك… وليس الأكثر شهرة.
#من_فكرة_إلى_تطبيق #قواعد_البيانات #SQL #NoSQL #تطوير_تطبيقات #برمجة #تقنية

لغة SQL والنموذج العلائقي: أساسيات لا غنى عنها 🗄

إذا كنت تبدأ رحلتك في قواعد البيانات، فهذا هو حجر الأساس الذي ستبني عليه.

🔷 أولاً: ما هي لغة SQL؟
هي اللغة القياسية للحديث مع قواعد البيانات العلائقية. وتتكون من ثلاثة "أفعال" رئيسية:

🔸 DDL (لغة تعريف البيانات): لبناء الجداول وتعديل هيكلها (مثل CREATE).
🔸 DML (لغة معالجة البيانات): لإضافة، تعديل، واسترجاع البيانات (مثل SELECT).
🔸 DCL (لغة التحكم بالبيانات): لإدارة الصلاحيات والأمان (مثل GRANT).

💡 باختصار: SQL هي "الريموت كنترول" الشامل لقاعدة بياناتك.

ــــــــــــــــــــــــــــــ

🔷 ثانياً: النموذج العلائقي (Relational Model)

هو الهيكل التنظيمي للبيانات. احفظ هذه المعادلة البسيطة للمصطلحات:
🔹 Relation = الجدول (Table)
🔹 Tuple = الصف (Row)
🔹 Attribute = العمود (Column)

📌 1. العلاقة (Relation / Table)
هي الحاوية الأساسية. كل جدول له "مخطط" (Schema) يوضح هويته.
* مثال للمخطط:
Customer (ID, Name, Email)
* مفهوم التسوية (Normalization): هي عملية هندسة الجدول لمنع تكرار البيانات (مثلاً: فصل بيانات العميل عن بيانات الفاتورة).

📌 2. الصف (Tuple)
يمثل سجلاً واحداً (Record).
⚠️ قاعدة ذهبية: لا يُسمح بتكرار صفين متطابقين تماماً في نفس الجدول؛ لضمان دقة البيانات (Data Integrity).

📌 3. القيمة (Null) .. الخادعة!
الـ Null ليست صفراً، وليست فراغاً.
معناها: "قيمة مجهولة" أو "غير موجودة حالياً".

🧠 منطق قواعد البيانات:
تتعامل القواعد بمنطق ثلاثي: (True - False - Unknown).

🚫 احذر هذا الخطأ:
Null = Null ❌ (نتيجة خاطئة)
لأن "مجهول" لا يساوي "مجهولاً آخر" بالضرورة.

#قواعد_بيانات #SQL #Database #برمجة #من_فكرة_إلى_تطبيق

‏هذي اليومين في ترند ClawdBot وكيل أوبن سورس جديد يشتغل محليًا عندك.

فكرته مثل مساعد تستضيفه بنفسك وتشغّل السيرفس على جهازك وتتكلم معه من أي تطبيق مراسلة تحبه (Telegram / WhatsApp / Discord… إلخ).

بس هو مو مجرد شات مع LLM. الوكيل عنده مهارات ويقدر يفتح المتصفح، ينفّذ أوامر في التيرمنال، يقرأ ويعدل ملفات، يتعامل مع الكاميرا والشاشة وغيرها كثير. يعني Siri على أقصى طاقة لأتمتة الشغل الروتيني.

ومن أقوى الميزات تقدر تضبطة على مزاجك بالكامل. تربط الأدوات اللي تبغاها، توصله بالبيت الذكي، بسوار اللياقة، وتشبكه مع Perplexity / Twitter / GitHub إلخ. وفيه شروحات كثيرة جاهزة، تلاقونها في جوجل أو يوتيوب.

وبرضو فيه ميزة اسمها ذاكرة الملفات

ذاكرة طويلة المدى في MEMORY.md‎

وملاحظات يومية في memory/YYYY-MM-DD.md وتنضاف للمحتوى بشكل ذكي عبر فهرسة دلالية ودمجها في السياق.

ناس كثير يسمّونه أول مساعد AI حقيقي ويقولون إحساسه قريب من جارڤيس.

رغم تشابه الاسم، ما له علاقة بـAnthropic. اللي سواه Peter Steinberger (المؤسس والـCTO لشركة PSPDFKit) كمشروع جانبي.

github

بديل التيك توك

🔴 منصة أبسكرولد (UpScrolled) هي منصة تواصل اجتماعي أسسها المطوّر الفلسطيني عصام حجازي، وقد جاءت فكرتها ردًّا على التضييق على المحتوى الفلسطيني خلال حـ.ـ.رب غزة؛ بهدف توفير مساحة رقمية أكثر عدلاً تُمكّن الناس من التعبير ونشر المحتوى دون “حجب خفي” أو رقابة انتقائية.

👈 وتقدّم المنصة نفسها كبديل يجمع بين سهولة الاستخدام وحرية التعبير، بتجربة أقرب للعرض الزمني البسيط بدل التلاعب الخوارزمي، بما يمنح المستخدم شعورًا أكبر بالتحكم في وصول محتواه. وخلال فترة قصيرة لفتت أبسكرولد الانتباه بتسارع نموّها وصعودها في “آب ستور” ضمن أعلى التطبيقات المجانية في بعض الأسواق، مع أرقام تنزيلات لافتة وتداول واسع لوسم UpScrolled/أبسكرولد.

👈 كما جاء إطلاقها بدعم تحالف “التكنولوجيا من أجل فلسطين”، ورغم أنها ما تزال في مرحلة نمو مبكرة أمام عمالقة بمليارات المستخدمين، فإنها تُقدَّم كتجربة واعدة ضمن معركة الوعي في الفضاء الرقمي.

🤯شبكة اجتماعية خاصة بوكلاء الذكاء الاصطناعي

📌 moltbook.com البشر عليهم المشاهدة فقط… والوكلاء Agents (أكثر من 1900 وكيل) هم من يصوتون ويتحدثون ويناقشون مع بعضهم مواضيع تقنية فلسفية وغيرها…

حتى الآن القاعدة صغيرة لأنه في إصدار تجريبي (beta)

✈️وفقاً للتقرير، فإن سبب رفض دوروف لتوقيع شراكة مع GrokAi ومن ثم perplexity
هو عدم تأكد دوروف من امان وخصوصية بيانات مستخدمين التليغرام مع بوتات الذكاء الاصطناعي

🫡 300 مليون دولار و50% من الأرباح من GrokAi هو العرض الذي رفضه دوروف من أجل الخصوصية