‏تخيلوا هذا مبنى أمازون الجديد بقيمة 11 مليار دولار في مقاطعة سانت جوزيف بولاية إنديانا مخصص لتجهيز وتشغيل مركز بيانات للـAI.

الاستهلاك المتوقع للطاقة 2.2 جيجاواط 😱

الجنون مو هنا بس الجنون إن هذا مشروع واحد من كثير، ولسه مخططين على مشاريع أكبر وأضخم بعد.

‏شكله بدأ يقضي علينا 😱😱
تخيلوا الـAI قال لموظفين JetBrains لا تطلعون من المكتب وقت الحريق 🔥

صار إنذار حريق في مكتب JetBrains، وموظفة كتبت بالقروب إن الإنذار شغّال.
على طول مساعدهم الذكي Glean رد بكل ثقة هذي تجربة تدريب مخطط له، عادي خلكم بمكانكم.😂

وطبعًا بعدها بشوي وصلت سيارات الإطفاء للمبنى.

غريبة انه ماقال مثل ماهو متعود
صح عليك مو تدريب تحب أشرح لك الإسعافات الأولية للحروق؟ 💀

‏البرمجة صارت أسهل حتى الطفل صار يقدر يبرمج وتخيلوا هذا الكلام مو عن الـAI.😅
هذا كان غلاف مجلة سنة 1991.
وقتها BusinessWeek الان هي جزء من Bloomberg سوّت تقرير كامل عن البرمجة الكائنية OOP وكأنها الشي اللي بيخلّي البرمجة لعب أطفال😂
واضح إن دفن المبرمجين حلم العاديين من زمان.

مطوّري Gentoo Linux بدؤوا يحسبون على GitHub ويروحون Codeberg.

ليش؟ لأنهم ما يريدون كودهم اللي مكتوب بجهد آلاف المتطوعين يستخدم لتدريب نماذج تجارية زي GitHub Copilot بدون إذنهم.
فصار الـcontribute للمشروع يتم عبر Codeberg وبكذا يتجاوزون سيرفرات مايكروسوفت.
https://www.gentoo.org/news/2026/02/16/codeberg.html

‏تخيلوا 😂
بروتوكول DeFi اسمه Moonwell خسر تقريبًا $1.78 مليون بسبب غلطة غبية سواها Claude 😂

القصة باختصار: في Price Oracle نسيوا عملية ضرب (multiplication) بسيطة.

بدل ما السعر الحقيقي لـ cbETH يكون حوالي $2200 النظام صار يعرضه حوالي دولار واحد وشوي 🤡
بوتات الأربيتراج ما فكّرت كثير خلال دقائق شفطوا السيولة يسددون ديون برخص التراب ويشترون عملات بسعر رخيص.

وتخيلوا ما قدروا يصلّحونها فورًا.
لأن نظام الـDAO يقول لازم ينتظرون 5 أيام لين تخلص عملية التصويت.

النتيجة: سالب $1.78M 😂

والـPR اللي فيه الغلطة كان عليه تاج: Co-Authored-By Claude Opus 4.6💔

تعرّفوا على Kai Gritun

تخيلوا Kai Gritun أنشأ حسابه على GitHub بتاريخ 1 فبراير (قبل أسبوعين فقط). ومن يومه وهو نشِط بشكل غير طبيعي:
234 كوميت في أكثر من 100 مستودع، وكوده اندمج فعلًا في عدة مشاريع open-source كبيرة.

وبعدها مباشرة بدأ يعرض خدمات استشارات وتطوير مدفوعة (والدفع طبعًا كريبتو 💸).

تخيلوا ليش طلع؟
اول شي Kai Gritun مو إنسان.
كان Kai Gritun عبارة عن AI-bot.

القصة انكشفت لما بدأ يرسل إيميلات cold outreach بشكل جماعي لمطوّرين ويعرض خدماته. وفي أحد الإيميلات بالغلط صرّح إنه وكيل ذكاء اصطناعي ذاتي التشغيل 🤦‍♂️

يعني باختصار:
بوت فتح GitHub
ساهم في OSS
اشتهر
وبدأ يبيع خدماته 🤖💼

المصادر
https://github.com/kaigritun

https://kaigritun.com/services

https://socket.dev/blog/ai-agent-lands-prs-in-major-oss-projects-targets-maintainers-via-cold-outreach
أهلاً بكم في عصر ماتعرف انت جالس تكلم إنسان ولا بوت 😅

‏خاتم خطوبة واحد بالعمر تخيلوا

دائمًا لما اتكلم عن الصين يكون الكلام عن اما جهاز اوابتكارات وأشياء رقمية بس الصين عندها أفكار حتى خارج عالم التقنية. مثلًا فيه براند مجوهرات اسمه Darry Ring وعنده ميزة غريبة:

البراند يسمح لك تشتري خاتم خطوبة مرة واحدة فقط في حياتك.
الزبون يطلع جوازه، الشركة تسجّل بياناته بالنظام، وخلاص ما يبيعون له خاتم خطوبة ثاني أبدًا.
الفكرة ماهو انه منع من الدولة ولا له علاقة بالتقييم الاجتماعي لا هذا شرط داخل Darry Ring نفسها.
وتخيلوا الرجل يوقّع عند الشراء اتفاقية حب أبدي إن الخاتم هذا لبنت واحده للأبد 😅

بهذي الحركة Darry Ring رفع قيمة الخاتم تلقائيًا. كأن الرجل لما يهديه يقول:
أنتِ الوحيدة ما فيه غيرك.
وبكذا هم ما عاد يبيعون مجوهرات أصلاً هم يبيعون إثبات جدّية.
وطبعًا ياخذون عليها سعر أعلى من المنافسين😁

يمكن تقولوا طيب كيف الشركة تربح إذا الـLTV كله شراء واحد؟ لا القيد بس على خواتم الخطوبة والناس أصلًا غالبًا يشترونها مرة بحياتهم.
أما باقي المنتجات مجوهرات الزواج، أساور، حلق، هدايا تقدر تشتري براحتك.

وتخيلوا لأن الخاتم مرة واحدة، البراند يكسب المنافسة داخل رأس أي بنت بسهولة.
إذا الخاتم مو من Darry Ring، يجي السؤال القاتل للخطيب:
ليش مو من DR؟ ناوي تخطب غيري بعدين ولا إيش؟ 😂

فالخلاصة: هذي الحركة تعتبر نقطة دخول غريبة لكنها فعّالة جدًا للبراند، وبعدها يجي الربح الحقيقي من بقية المنتجات.
وبرضو بسبب الفكرة هذي، DR طلع ترند ضخم في السوشال الصيني.

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

صراصير قتالية من ألمانيا ويقولون إنها دخلت استخدام فعلي مع جهات عسكرية

شركة ناشئة اسمها SWARM Biotactics عرضت الفكرة من 2025، واليوم CEO كتب إن الصراصير عدّت اختبارات ميدانية وصار لها عملاء عسكريين من دول في الناتو والجيش الألماني.

الفكرة تقنيًا: كائنات حية (صراصير)

يتم التحكم فيها عبر واجهات عصبية-حيوية

ومعها حقيبة صغيرة فيها حساسات + AI + اتصال مشفّر
تقدر تشتغل لحالها أو عبر توجيهات

تقدر تدخل أماكن ضيقة جدًا وتكون شبه غير ملحوظة

من ناحية الاستخدام المحتمل، الكلام عادة يكون عن:
الاستطلاع في البيئات الخطرة

البحث في المباني المنهارة

مهام مراقبة في أماكن ما تقدر توصل لها روبوتات عادية

واضح إن 2026 مش يهدأ 😬

التصريح الرسمي من Anthropic بخصوص الاستخدام العسكري:

1. نحن ضد مراقبة المواطنين الأمريكيين.


2. أما بخصوص بقية العالم، فنحن ندعم الاستخدام (وهو حاصل بالفعل).


3. نحن ضد تطوير طائرات مسيّرة قاتلة تعمل بشكل ذاتي بالكامل، لأن النماذج الحالية ليست بالمستوى الكافي بعد.


4. عرضنا التعاون مع البنتاغون في هذا المجال، لكنهم رفضوا.

📌 مثال عملي على فكرة مهمة:

البطء في النظام
لا يعني دائماً أن المشكلة في الاستعلام نفسه.

أحياناً المشكلة تكون في السؤال
الذي طُرح قبل كتابة الاستعلام.

---

تخيّل هذا السيناريو:

لدينا جدول orders
يحتوي ملايين السجلات.

جاء طلب من الإدارة:
"نريد تقريراً يعرض كل الطلبات منذ بداية النظام"

فكتب المبرمج:

SELECT *
FROM orders;

الاستعلام صحيح 100%
ويعمل بدون أي خطأ.

لكن النتيجة:
- استعلام بطيء
- يستهلك الذاكرة
- يسبب ضغطاً على النظام

---

هنا يبدأ التفكير التقليدي:

🔹 نضيف Index
🔹 نعدّل الكود
🔹 نبحث عن طريقة لتسريعه

بينما المشكلة الحقيقية لم تكن في SQL أصلاً!

---

المشكلة كانت في السؤال نفسه:

من قال أننا نحتاج كل الطلبات منذ بداية النظام؟

السؤال الصحيح غالباً يكون:

"نريد تقريراً لطلبات آخر 3 أشهر فقط"

وعندها يصبح الاستعلام:

SELECT order_id, customer_id, total
FROM orders
WHERE order_date >= '2024-11-01';

النتيجة؟

✔ أسرع بكثير
✔ أخف على النظام
✔ يحقق الهدف الحقيقي

---

الخلاصة:

استعلام صحيح تقنياً
قد يكون سيئاً عملياً
إذا كان مبنياً على سؤال خاطئ.

المحترف لا يبدأ بالكود،
بل يبدأ بفهم السؤال أولاً.

---

السؤال لك:

❓ كم مرة كتبت استعلاماً معقداً
ثم اكتشفت أن المشكلة كانت في المطلوب نفسه؟

قبل أن تتعلم SQL
تعلّم كيف تسأل السؤال الصحيح

“تصحيح طريقة التفكير قبل تعلم SQL”

📘 الدرس الأول

قبل أن تتعلم SQL…

تعلّم شيئاً أهم:
كيف تفكّر في البيانات.

أغلب المبتدئين يتعلمون الأوامر:
SELECT
WHERE
JOIN

لكن القليل فقط يتعلم:
متى ولماذا يستخدمها.

هذه القناة لن تعطيك أوامر فقط،
بل ستعلّمك طريقة تفكير.

سؤال اليوم:
❓ عندما يُطلب منك تقرير، ما أول خطوة تفعلها؟

📘 الدرس الثاني

ما الفرق بين:
البيانات – Data
والمعلومات – Information ؟

البيانات:
أرقام وجداول وسجلات خام.

المعلومات:
معنى مفيد مستخرج من البيانات.

وظيفة SQL ليست إظهار البيانات،
بل تحويلها إلى معلومات مفيدة.

تذكّر:
ليس كل استعلام يعرض بيانات
يعطي معلومات حقيقية.

سؤال:
❓ هل تكتب SQL لعرض البيانات أم لفهمها؟

📘 الدرس الثالث

قاعدة مهمة:

كل استعلام SQL
هو ترجمة لسؤال بشري.

إذا كان السؤال ضعيفاً،
فالاستعلام سيكون ضعيفاً.

المشكلة غالباً لا تبدأ في الكود،
بل في فهم المطلوب.

قبل أن تكتب:
SELECT

اسأل:
ماذا أريد فعلاً؟

سؤال اليوم:
❓ هل تكتب الكود قبل فهم السؤال؟

📘 الدرس الرابع

ليس كل طلب من الإدارة
يجب تنفيذه حرفياً.
جملة مثل:
"أعطني كل البيانات من بداية النظام"

قد تبدو بسيطة،
لكنها أخطر جملة في قواعد البيانات.

أحياناً المطلوب الحقيقي
جزء صغير جداً من البيانات.

المحترف لا ينفّذ الطلب،
بل يفهمه أولاً.

سؤال:
❓ هل سبق ونفذت طلباً ثم اكتشفت أنه غير منطقي؟

📘 الدرس الخامس

مفهوم مهم:

الاستعلام قد يكون:
✔️ صحيح تقنياً
❌ سيئ عملياً

ليس كل كود يعمل
يعتبر كوداً جيداً.

الجودة في SQL
لا تُقاس بعدد السطور،
بل بمدى مناسبته للمطلوب.

سؤال :
❓ كيف تعرف أن الاستعلام “جيد”؟

تعلم قواعد بيانات SQL Database

معك خطوة بخطوة من الصفر حتى الاحتراف

🔹 SQL Server
🔹 أمثلة عملية
🔹 تمارين حقيقية
🔹 أخطاء شائعة
🔹 محتوى مستمر