‏تخيلوا Gemini صار يعرف عنك كل شيء 💔

قوقل أطلقت Personal Intelligence وربطوا Google Photos و YouTube داخل سياق Gemini.

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

المهم هنا مو مجرد إنه صار يفتح الصور الفكرة إنه صار يفهم معناها ويربط بينها. لأن Google Photos مخزن لا نهائي، ممكن فيه صور لعشرات السنين سياق ضخم جدًا على أي LLM.
الآن نفهم ليه التخزين كان فترة طويلة ببلاش واضح كانوا عارفين وين رايحين. أو يمكن هذا مجرد مثال عبقري لدمج تقنية جديدة داخل منظومة جاهزة.

الميزة مابتكون شغّالة تلقائيًا (مقفلة افتراضيًا).

والخطوة الجاية شكلها تقول بصوتك احجز لي عند بنشر قريب ويحجز لك حول بيتك.😅

حاليًا قاعدين يطلقونها تدريجيًا لمشتركين أمريكا.

مراجعة جيدة على مجموعة من الهواتف الأوروبية التي تعمل بعيدًا عن خدمات جوجل: أندرويد معدل أو لينكس للهواتف.

هذه بدائل ممتازة للشخصيات الأمنية أو المهتمين بالخصوصية أو المؤسسات الحساسة، ويجب أن يكثر استيرادها لبلادنا، ومستقبلا تصنيعها بأيدينا (ولدينا القدرة على ذلك بلا شك).
https://tuta.com/blog/degoogled-phones

فتح موقع تويتر الشفرة المصدرية لخوارزميات اقتراح المحتوى الخاصة به.
https://github.com/xai-org/x-algorithm

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

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

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

هذه أدوات الذكاء الاصطناعي التي ستجعل حياتكم أسهل! 🚀

هل تريدون حل الواجبات، إنشاء العروض، تحرير الملفات، أو ابتكار الفيديوهات؟ إليكم أفضل 13 أداة AI يمكنكم استخدامها اليوم:

✅ ChatGPT.com → حل أي سؤال أو واجب بسهولة
✅ LightPDF.com → تحدث مع ملفاتك وحرّرها بسرعة
✅ Tome.app → اصنع عروض تقديمية رائعة
✅ Pika.art → أنشئ فيديوهات مبتكرة
✅ Gamma.app → صمّم مستندات باحتراف
✅ PicWish.com → تعديل وتحسين الصور
✅ Perplexity.ai → مساعدك الذكي في البحث
✅ Krea.ai → تصميم شعارات جذابة
✅ Fliki.ai → تعليق صوتي احترافي
✅ Runway.ml → مونتاج أفلام وفيديوهات
✅ Relume.io → تصميم مواقع ويب بسهولة
✅ LumaLabs.ai → إنشاء نماذج ثلاثية الأبعاد
✅ Descript.com → تعديل الصوت والفيديو بدقة

⭐️ نصيحة: استغلوا هذه الأدوات لتسهيل دراستكم، تطوير مشاريعكم، وإظهار إبداعكم!👨‍💻

‏واغفر لنا حين يذهب عنّا الأصحاب ..
اللهُم الثبّات يوم لاحولَ لنا ولا قوة 🤲🏻

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

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

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 #قواعد_البيانات