إجابة السؤال:

كيف نتعامل مع "حالة الموعد" (Appointment Status)؟

في تصميم قواعد البيانات، لدينا خياران للتعامل مع الحالات الثابتة مثل حالة الموعد (معلق، مؤكد، مكتمل... الخ):

الخيار الأول (ENUM / Text):

أن نضع الحالة كحقل نصي عادي داخل جدول Appointments.

العيوب:

إذا أردنا مستقبلاً إضافة حالة جديدة (مثل: "قيد الانتظار في العيادة")، أو أردنا تغيير كلمة "ملغى" إلى "تم الإلغاء"، سنضطر لتعديل هيكل قاعدة البيانات أو تحديث آلاف السجلات السابقة، مما يستهلك موارد السيرفر.

الخيار الثاني (جدول مرجعي - Lookup Table) :

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

المميزات:

سهولة إضافة حالات جديدة برمجياً دون المساس بهيكل قاعدة البيانات، وتسهيل عملية الترجمة (إذا كان النظام يدعم لغتين).

سنعتمد الخيار الثاني في تصميمنا ليكون احترافياً وقابلاً للتوسع.

الخطوة الثانية:
تحديد العلاقات (Relationships) والمفاتيح (PK & FK)

الآن سنربط الجداول ببعضها بناءً على المنطق الطبيعي للعيادة.

في هذه الخطوة سنحدد المفتاح الأساسي
(Primary Key - PK)
الذي يميز كل سجل، والمفتاح الأجنبي (Foreign Key - FK) الذي يربط جدولاً بآخر.

1. العلاقة بين (المرضى) و (المواعيد):

المريض الواحد يمكن أن يكون لديه عدة مواعيد، لكن الموعد الواحد يخص مريضاً واحداً.

نوع العلاقة:
واحد إلى متعدد (1:N).

التطبيق:
نضيف PatientID كمفتاح أجنبي (FK) في جدول Appointments.

2. العلاقة بين (الأطباء) و (المواعيد):

الطبيب الواحد يمكن أن يكون لديه عدة مواعيد، لكن الموعد الواحد مخصص لطبيب واحد.

نوع العلاقة:
واحد إلى متعدد (1:N).

التطبيق:
نضيف DoctorID كمفتاح أجنبي (FK) في جدول Appointments.

3. العلاقة بين (حالات المواعيد) و (المواعيد):

الحالة الواحدة (مثل: معلق) يمكن أن ترتبط بعدة مواعيد.

نوع العلاقة:
واحد إلى متعدد (1:N).

التطبيق:
نضيف StatusID كمفتاح أجنبي (FK) في جدول Appointments.

4. العلاقة بين (المواعيد) و (السجلات الطبية):

المتطلبات تقول: "يجب أن يكون هناك سجل طبي لكل موعد حضور".
هذا يعني أن السجل الطبي ناتج عن موعد محدد.

نوع العلاقة:
واحد إلى واحد (1:1).

التطبيق: نضيف AppointmentID كمفتاح أجنبي (FK) في جدول Medical_Records.

5. العلاقة بين (السجلات الطبية) و (الوصفات الطبية):

المتطلبات تقول:
"وصفة طبية واحدة على الأكثر لكل سجل طبي".

نوع العلاقة:
واحد إلى واحد (1:1).

التطبيق:
نضيف RecordID كمفتاح أجنبي (FK) في جدول Prescriptions.

6. العلاقة بين (المواعيد/المرضى) و (المدفوعات):

المتطلبات تقول:
"الدفع لكل موعد". الموعد الواحد قد يتم دفعه دفعة واحدة او أقساط

نوع العلاقة:
واحد إلى واحد (1:1) إذا كان الدفع مرة واحدة

(أو 1:N في حال كان هناك دفع بالتقسيط، لكن سنفترض 1:1 لتبسيط العيادة).

التطبيق:
نضيف AppointmentID كمفتاح أجنبي (FK) في جدول Payments.

تحديث الجداول بعد إضافة المفاتيح
(تمهيداً للخطوة الثالثة):
Patients
(PK: PatientID)

Doctors
(PK: DoctorID)

Appointment_Statuses (PK: StatusID)

Appointments
(PK: AppointmentID | FK: PatientID, DoctorID, StatusID)

Medical_Records
(PK: RecordID | FK: AppointmentID, PatientID, DoctorID)

Prescriptions
(PK: PrescriptionID | FK: RecordID)

Payments
(PK: PaymentID | FK: AppointmentID, PatientID)

للخطوة الثالثة
(تحسين التصميم - Normalization):

في جدولي Medical_Records و Payments،

المتطلبات طلبت صراحةً تخزين (المريض والطبيب).

ولكننا قمنا بربطهما بجدول الموعد AppointmentID (والذي بدوره يحتوي أصلاً على معرف المريض ومعرف الطبيب).

برأيك التحليلي:

هل من الأفضل أن نبقي PatientID و DoctorID
في جدول السجلات الطبية والمدفوعات كما طلبت المتطلبات حرفياً؟

أم نقوم بحذفهما والاكتفاء بـ AppointmentID لمنع تكرار البيانات
(Data Redundancy)

هذا ما سنعرفه حاليا وهنا يكمن مربط الفرس وتفكير المهندس ؟

وهنا تعرف الحق من الباطل
وتعرف بأنك أضعت نفسك في جعل الذكاء الاصطناعي يشتغل كل شي بدلاً عنك وأنت لا تعرف ماذا يدور بالضبط

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

إجابة سؤال
(تحسين التصميم - Normalization):

الإجابة الصحيحة هندسياً هي:

يجب أن نحذف PatientID و DoctorID من جدولي السجلات الطبية والمدفوعات، ونكتفي بـ AppointmentID فقط.

لماذا؟
هذا المبدأ يسمى بمنع تكرار البيانات
(Data Redundancy)
وحماية قاعدة البيانات من التعارض (Anomalies).

بما أن السجل الطبي والعملية المالية مرتبطان بـ "موعد" محدد، والموعد نفسه يحتوي مسبقاً على (رقم المريض ورقم الطبيب)، فلا حاجة لتكرارهما.

لو أبقيناهما، قد يحدث خطأ كارثي مستقبلاً؛ كأن يتم إدخال AppointmentID يخص "أحمد"،

بينما نضع بالخطأ PatientID يخص "خالد" في نفس السجل المالي!

بالاكتفاء بـ AppointmentID، نضمن أن الدفع والسجل الطبي يذهبان للمريض والطبيب الصحيحين دائماً
(عن طريق عملية JOIN في SQL).

الخطوة الرابعة:
المخطط العلائقي النهائي (Relational Schema)

الآن، وبعد أن استخرجنا الكيانات، وحددنا العلاقات، ونظفنا التصميم من التكرار، إليك التصميم النهائي والاحترافي لقاعدة بيانات العيادة.

مفتاح القراءة :
PK =
مفتاح أساسي،
FK =
مفتاح أجنبي يربط بجدول آخر

1. جدول المرضى (Patients)

PatientID (PK)

Name

DateOfBirth

Gender

Phone

Email

Address

2. جدول الأطباء (Doctors)

DoctorID (PK)

Name

Specialization

DateOfBirth

Gender

Phone

Email

Address

3. جدول حالات المواعيد (Appointment_Statuses)

StatusID (PK)

StatusName
(مثل: معلق، مكتمل، ملغى...)

4. جدول المواعيد (Appointments)

AppointmentID (PK)

PatientID
(FK -> يربط بجدول المرضى)

DoctorID
(FK -> يربط بجدول الأطباء)

StatusID
(FK -> يربط بجدول الحالات)

DateTime

5. جدول السجلات الطبية (Medical_Records)

RecordID (PK)

AppointmentID
(FK -> يربط بجدول المواعيد)

VisitDescription

Diagnosis

AdditionalNotes

6. جدول الوصفات الطبية (Prescriptions)

PrescriptionID (PK)

RecordID
(FK -> يربط بجدول السجلات الطبية)

MedicationName

Dosage

Frequency

StartDate

EndDate

SpecialInstructions

7. جدول المدفوعات (Payments)

PaymentID (PK)

AppointmentID
(FK -> يربط بجدول المواعيد)

PaymentDate

PaymentMethod

AmountPaid

AdditionalNotes

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

فلقد أُصبنا بالتبلد الفكري والعجز بسبب الاعتماد على الذكاء الاصطناعي بتنفيذ هذا العمل

لا أمنعك من استخدام الذكاء الاصطناعي نهائياً فهذا تخلف أيضا ولكن لا تجعله يقتل تفكيرك

يا عزيزي استخدمه بطريقة افضل خليه يشرح لك كيف تحلل ؟ كيف تصمم ؟ كيف تسوي الكيانات والخصائص والعلاقات
كيف تحسن وتطبع الجداول
كيف تحسن الاستعلامات ؟

ارسم له بورقة وصور له وخليه يصحح لك اكتشف اخطائك واتعلم

عمر الاعتراف بالخطأ ما كان عيب

العيب أن تستمر في أخطائك
وانت في الحقيقة في وهم بأنك فاهم

طبيعي جداً أن تعود للاساسيات وتصلح اخطائك ونقاط ضعفك.

ماهي الخطوات التي يمر بها مهندس البرمجيات بعد هذه الخطوة كيف يسوي الان

كيف يرسم المخططات ؟
كيف يختار معمارية النظام ؟
كيف يهيكل المشروع ؟
كيف يختار برمجة وظيفية ام كائنية ؟
كيف يصمم خوارزميات التنفيذ ؟
كيف يختار التقنيات المستخدمة ؟
كيف يصمم الواجهات قبل التنفيذ ؟
كيف يشتغل كفريق في هذا المشروع ؟
كيف يقسم الأدوار والمهام ؟
كيف يحدد الخطة الزمنية لكل مهمة متى تبدأ ومتى تنتهي ؟
أي مهمة تبدأ أولاً ؟
كيف اشتغل انا وفريقي عن بُعد من البيت ؟
كيف ندمج العمل تبعنا ؟
ما أسباب التعارض الذي يحدث بالمشروع عندما نشتغل كفريق ؟
كيف نحل مشكلة الدمج والتكامل خاصة إذا كانت التقنيات مختلفة ؟
ما مشاكل الباك اند مع الفرونت اند والعكس ؟


هل يبدأ مطور الباك اند ام مطور الفرونت اند
أي اطار عمل او لغة نختارها سوى بالفرونت أوالباك ؟

هذا ما سنعرفه في الأيام القادمة
كونوا معنا
#يوميات_مهندس

هذا المخطط (Solution)

يقدم أفكاراً متقدمة واحترافية جداً في هندسة قواعد البيانات!

لقد نقل التصميم من مستوى "أساسي" إلى مستوى "قابل للتوسع المؤسسي"

إليك تحليلي المعماري لهذا المخطط، مبرزاً نقاط القوة ونقطة واحدة تستحق النقاش:

1. الضربة القاضية
(الوراثة - Supertype/Subtype)
الميزة الأقوى والأكثر ذكاءً في هذا المخطط هي إنشاء جدول Persons.


الفكرة:
بدلاً من تكرار الحقول المشتركة مثل الاسم Name ، وتاريخ الميلاد DateOfBirth ، والجنس Gender ، ورقم الهاتف PhoneNumber ، والبريد Email ، والعنوان Address في كل من جدولي المرضى Patients والأطباء Doctors ، قام بجمعها في "جدول أب" Persons.


الربط: ثم قام بإنشاء جدولي المرضى والأطباء وربطهما بالجدول الأب عبر المفتاح الأجنبي PersonID.

لماذا هذا رائع؟
1. يمنع التكرار نهائياً
(DRY Principle):
قاعدة البيانات أصبحت أنظف.

2. قابلية التوسع (Scalability):
إذا أردت غداً إضافة موظفي استقبال أو ممرضين، لن تضطر لإنشاء جداول ببيانات مكررة، بل ستنشئ جدول Nurses وتربطه بـ Persons.

3. يحل حالات نادرة
(Edge Cases):
ماذا لو مرض الطبيب وأصبح مريضاً في نفس العيادة؟ بهذا التصميم، سيكون له سجل واحد فقط في Persons ، ونربطه بجدول المرضى والأطباء معاً!

2. تحليل العلاقات المعكوسة (نقطة للنقاش)
هناك قرار تصميمي مثير للاهتمام في جدول المواعيد Appointments:

وضع المصمم المفاتيح الأجنبية MedicalRecordID و PaymentID داخل جدول المواعيد Appointments.

رأيي كمهندس نظم:
هذا تصميم صالح برمجياً لتمثيل علاقة (1:1 أو 1:0..1)،
ولكنه يعني أن هذه الحقول ستكون فارغة (NULL)
عند حجز الموعد لأول مرة،
ولن تُملأ إلا بعد إتمام الزيارة والدفع.

التصميم البديل
(الذي ناقشناه سابقاً):
وضع AppointmentID داخل جدول السجلات الطبية والمدفوعات هو الطريقة الأكثر شيوعاً؛ لأن السجل الطبي والدفع هما "كيانات تابعة" (Dependent Entities) للموعد، وتُنشأ بسببه.

كلا الحلين يعمل، لكن وضع المفتاح في الكيان التابع يقلل من حقول الـ NULL في قاعدة البيانات.

3. إدارة الحالات (Status)
لاحظ أنه استخدم نوع البيانات tinyint
لحقل AppointmentStatus.

الميزة: هذا يوفر مساحة كبيرة في قاعدة البيانات وتكون الاستعلامات فيه أسرع.

التطبيق البرمجي:
هذا يعني أنه سيعتمد على الباك اند (Backend) لترجمة هذه الأرقام
مثلاً:
1 = Pending،
2 = Confirmed
باستخدام (Enum Classes)، متخلياً عن فكرة جدول الـ
(Lookup Table)
المنفصل في قاعدة البيانات.

وهو أسلوب متبع جداً ومفضل لدى الكثير من المطورين لتسريع النظام.

بشكل عام، المخطط ممتاز للتدريب ويمثل خطوة متقدمة جداً في التفكير المعماري.

أولاً: الكيانات والخصائص
(Entities & Attributes)

1. جدول الأشخاص (Persons)

PersonID (int):
مفتاح أساسي (PK)

Name (nvarchar(100)): الاسم

DateOfBirth (date):
تاريخ الميلاد

Gender (nvarchar(1)): الجنس

PhoneNumber (nvarchar(20)): رقم الهاتف

Email (nvarchar(100)): البريد الإلكتروني

Address (nvarchar(200)): العنوان




2. جدول المرضى (Patients)

PatientID (int): مفتاح أساسي (PK)

PersonID (int): مفتاح أجنبي (FK)



3. جدول الأطباء (Doctors)

DoctorID (int):
مفتاح أساسي (PK)

PersonID (int): مفتاح أجنبي (FK)

Specialization (nvarchar(100)): التخصص




4. جدول المواعيد (Appointments)

AppointmentID (int):
مفتاح أساسي (PK)

PatientID (int):
مفتاح أجنبي (FK)

DoctorID (int):
مفتاح أجنبي (FK)

AppointmentDateTime (datetime):
تاريخ ووقت الموعد

AppointmentStatus (tinyint):
حالة الموعد

MedicalRecordID (int): مفتاح أجنبي (FK)

PaymentID (int):
مفتاح أجنبي (FK)



5. جدول السجلات الطبية (MedicalRecords)

MedicalRecordID (int): مفتاح أساسي (PK)

VisitDescription (nvarchar(200)):
وصف الزيارة

Diagnosis (nvarchar(200)):
التشخيص

AdditionalNotes (nvarchar(200)):
ملاحظات إضافية




6. جدول الوصفات الطبية (Prescriptions)

PrescriptionID (int):
مفتاح أساسي (PK)

MedicalRecordID (int): مفتاح أجنبي (FK)

MedicationName (nvarchar(100)):
اسم الدواء

Dosage (nvarchar(50)): الجرعة

Frequency (nvarchar(50)):
التكرار

StartDate (date):
تاريخ البدء

EndDate (date):
تاريخ الانتهاء

SpecialInstructions (nvarchar(200)):
تعليمات خاصة




7. جدول المدفوعات (Payments)

PaymentID (int):
مفتاح أساسي (PK)

PaymentDate (date):
تاريخ الدفع

PaymentMethod (nvarchar(50)):
طريقة الدفع

AmountPaid (decimal): المبلغ المدفوع

AdditionalNotes (nvarchar(200)):
ملاحظات إضافية




🔗 ثانياً: العلاقات (Relationships)

بناءً على المفاتيح الأجنبية (Foreign Keys)، يتم ربط الجداول كما يلي:

1. علاقة الأشخاص بالمرضى والأطباء
(Supertype / Subtype)

جدول Persons يمثل الكيان العام (Supertype).

جدول Patients و Doctors يمثلان كيانات فرعية (Subtypes).

الربط يتم عبر:

PersonID → Patients

PersonID → Doctors


كل مريض أو طبيب هو في الأصل "شخص".



2. علاقة المواعيد بالمرضى

جدول Appointments يرتبط بجدول Patients عبر:

PatientID (FK)


العلاقة:
Patient (1) → (M) Appointments




3. علاقة المواعيد بالأطباء

جدول Appointments يرتبط بجدول Doctors عبر:

DoctorID (FK)


العلاقة:
Doctor (1) → (M) Appointments



4. علاقة المواعيد بالسجلات الطبية

جدول Appointments يرتبط بجدول MedicalRecords عبر:

MedicalRecordID (FK)


العلاقة:
Appointment (1) → (1) MedicalRecord (غالبًا)



5. علاقة المواعيد بالمدفوعات

جدول Appointments يرتبط بجدول Payments عبر:

PaymentID (FK)


العلاقة:
Appointment (1) → (1) Payment



6. علاقة الوصفات الطبية بالسجلات الطبية

جدول Prescriptions يرتبط بجدول MedicalRecords عبر:

MedicalRecordID (FK)


العلاقة:
MedicalRecord (1) → (M) Prescriptions


التصميم يطبق Normalization
بشكل ممتاز (تقليل التكرار).

استخدام
Supertype/Subtype

(Persons →
Patients/Doctors).

النظام قابل للتوسعة
(مثلاً إضافة Nurse أو Admin بسهولة)

بِسْمِ اللَّهِ الرَّحْمَنِ الرَّحِيم
الحمدُ للهِ القائل:
﴿يَرْفَعِ اللَّهُ الَّذِينَ آمَنُوا مِنكُمْ وَالَّذِينَ أُوتُوا الْعِلْمَ دَرَجَاتٍ﴾

لقد ختمنا رحلةً امتدت لأربع سنوات من الجهد، والسهر، والطموح، لنقف على أعتاب مرحلة جديدة نحمل فيها ثمرة ما تعلمناه، وتجسيداً عملياً لمسيرة علمية وتقنية

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

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

ومع دخولنا مرحلة مشروع التخرج، لم يكن الهدف تنفيذ فكرة فقط، او التخلص من عبئ مشروع التخرج ، بل بناء نظام متكامل يعالج مشكلة واقعية، بدءاً من تحليل احتياجات المستخدمين، مروراً بالتصميم المعماري (System Architecture)، وانتهاءً بربط جميع المكونات في بيئة واحدة تعمل بتناغم واحترافية.

هنا مشروعنا بعنوان:
“وكيلك الذكي للتسوق”

وهو نظام تقني متكامل بمستوى متعدد الصلاحيات والمتاجر يهدف إلى تطوير تجربة التسوق، وربط العملاء بالمتاجر المحلية بطريقة ذكية وسهلة.

يتكون المشروع من ٤ منظومات رئيسية:

لوحة تحكم إدارية لإدارة النظام ومتابعة الأداء..الخ
لوحة تحكم للتجار لإدارة المنتجات والعروض والتخفيضات..الخ
تطبيق موبايل للمستخدم لتجربة تسوق سلسة واحترافية.
واجهات خلفية بمعمارية متعددة الطبقات (Multi-tier Architecture)
ليكون منصة (SaaS) متكاملة وقابلة للتوسع

تتواصل واجهات النظام المختلفة (تطبيق الموبايل الخاص بالعملاء، ولوحات تحكم الويب الخاصة بالتجار والإدارة) مع خادم مركزي عبر واجهة برمجة التطبيقات (API)

لم يكن المشروع تقليدياً، بل تميز بدمج حقيقي لتقنيات الذكاء الاصطناعي كجزء أساسي من النظام، ومن أبرز هذه المزايا:

١- وكيل ذكي (AI Agent) يساعد المستخدم وينفذ المهام داخل النظام ، مدمج بنظام محادثة ذكي (Chatbot)
٢- البحث عن المنتجات باستخدام الصور
٣- توليد وصف تسويقي ذكي للمنتجات
٤- نظام توصيات يعتمد على سلوك المستخدم

هذا التكامل بين هندسة البرمجيات والذكاء الاصطناعي يعكس حجم التحول المعرفي الذي مررنا به خلال هذه السنوات.

ورغم التحديات التي واجهتنا من الفكرة الى التخطيط الى التحليل الى تصميم قواعد البيانات و الواجهات ، إلى إدارة التكامل بين الأنظمة المختلفة بتقنيات مختلفة والربط عن طريق APIs، واختيار المعمارية المناسبة إلا أن كل تحدٍ كان خطوة نحو بناء فهم أعمق وخبرة أقوى.

وفي هذه اللحظة، لا يسعنا إلا أن نحمد الله حمداً كثيراً طيباً مباركاً فيه، فبفضله وتوفيقه وصلنا إلى ما نحن عليه اليوم.

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

ونعبر عن خالص تقديرنا لأساتذتنا الكرام، الذين أناروا لنا طريق العلم، وأسهموا في تشكيل هذا المستوى الذي وصلنا إليه.

كما نشكر لجنة المناقشة على ملاحظاتهم القيّمة التي أثرت مشروعنا، ومشرفينا الذين كان لهم الدور الأكبر في توجيهنا ومتابعتنا.

ولا ننسى فخرنا الكبير بفريق العمل، الذي جمعنا معه التعب، والأمل، والعمل الجماعي الحقيقي، فكنا مثالاً للتعاون والالتزام والتطوير الذاتي والبحث والإطلاع والتوسع وعدم الإكتفاء.

المهندسين :
م. ايمن قمحان
م. حازم العمري
م ضياء الحضرمي
م. طارق العمري
م. علي القواس

ختاماً…
مشروع التخرج ليس مجرد إسقاط واجب علينا، بل هو خلاصة أربع سنوات من التعلم، والتجربة، والفشل، والتحسين، والعمل الجماعي.

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

اللهم بارك لنا في هذا الإنجاز، واجعل القادم أجمل.
#DemoSoft

"يُنهكنا السهر ويأكل الإرهاق أرواحنا، لكنه احتراقٌ مُقدس يترك وراءه أثراً.... فالعمرُ سيمضي بنا في كل حال.. فليكن ضياؤه في وهجِ له معنى، لا انطفاءً في عتمة الهامش..
💙