Engr. Wael Alaswad

وأنا شغال على نظام التنبيهات FlexNotifyV2، اتعلمت إن النجاح مش إن الإيميل يوصل وخلاص.

في الواقع، فيه 3 حاجات مهمة جدًا لازم تحصل:

1) ما يتبعتش الإشعار أكثر من مرة
لأن الإشعارات المكررة تزعج المستخدم وتفقده الثقة في النظام.
عشان كده عملت dedupe لمنع التكرار.

2) الإشعار يتعالج بشكل صحيح
بدل ما الإرسال يكون مباشر وفوضوي، استخدمت queue processing
علشان الترتيب، الاعتمادية، وإدارة الحمل بشكل أفضل.

3) الوقت يظهر بشكل يفهمه المستخدم
كثير من الأنظمة تسجّل التوقيت بـ UTC،
لكن لو أرسلته للمستخدم كما هو، سيلخبطه.
عشان كده حولت التوقيت إلى الوقت المحلي
والنتيجة كانت إيميل واضح وبتوقيت صحيح.

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

وده بالضبط الفرق بين demo سريع
ونظام ينفع في الواقع.

اكتب في الكومنت: Queue
ولو حابين، أعمل ريل أشرح فيه
ليه deduplication و queue مهمين في أي نظام تنبيهات

واحد من الناس بعتلي سؤال ذكي جدًا بعد الريل اللي فات:

لو الـ Wi-Fi مش reliable في مشروع IoT… إيه البديل من غير ما التكلفة تزيد؟

والإجابة الحقيقية:
مفيش إجابة واحدة لكل المشاريع.

الاختيار الصح بيتحدد حسب:

طبيعة الموقع
المسافة
كمية البيانات
أهمية الجهاز
وهل فيه بنية تحتية موجودة أو لا

لو المكان ثابت وفيه بنية تحتية:
فالـ Ethernet غالبًا من أفضل الحلول من ناحية الثبات والتكلفة.

لو لازم Wireless:
ما تستعجلش وتلغي الـ Wi-Fi.
أحيانًا المشكلة مش فيه… المشكلة في design ضعيف:

مفيش retry
مفيش reconnect handling
مفيش buffering
مكان الأنتينا غلط
أو الشبكة نفسها غير مناسبة

لو المكان بعيد أو مفتوح:
هنا يبدأ التفكير في:

LoRa لو البيانات بسيطة والمسافة كبيرة
4G لو محتاج اتصال مباشر بالإنترنت
أو gateway architecture حسب المشروع

الخلاصة:
القرار الصح مش:
إيه أرخص وسيلة اتصال؟

لكن:
إيه أرخص وسيلة تحقق الاعتمادية المطلوبة فعلًا؟

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

اكتب IoT في الكومنت
ولو تحبوا، أنزل الجزء الجاي عن:
إمتى أستخدم Wi-Fi، وإمتى Ethernet، وإمتى LoRa، وإمتى 4G؟

#برمجة