Hossam Assadallah-حسام اسدالله

Hossam Assadallah-حسام اسدالله Contact information, map and directions, contact form, opening hours, services, ratings, photos, videos and announcements from Hossam Assadallah-حسام اسدالله, Information Technology Company, العنوان: East Lane 340, 340 South 90 Street, New Cairo Governorate (أمام كونكورد بلازا), Cairo.
(1)

حسام أسدالله — Hossam Assadallah
CEO & Founder @ Gooshylx | الرئيس التنفيذي ومؤسس جووشايلكس

Oracle APEX Architect & Full-Stack Developer
Building Scalable ERP, POS & AI-Powered Business Systems

خبرة أكثر من 20 سنة في تطوير أنظمة الأعمال: أنظمة ERP، نقاط

17/09/2026

في تطبيقات المؤسسات الكبيرة، مش بتلاقي كل حاجة في سكيمة واحدة. ممكن يكون عندك سكيمة HR، وسكيمة تانية للـ Finance، وتالتة للـ Inventory... إلخ. الكود بتاعك بيتصل بقاعدة البيانات باستخدام user معين (يبقى ده الـ Schema A)، لكن الـ package اللي محتاج تناديها فعليًا "ساكنة" في سكيمة تانية (Schema B).

المشكلة إن Oracle مبيفرقش في رسالة الخطأ بين "الكائن مش موجود"، "الكائن موجود بس معطوب"، "الاسم غلط"، أو "الصلاحيات ناقصة" — كل دول بيطلعوا نفس الرسالة بالظبط:
PLS-00201: identifier 'SCHEMA_B.PKG_SOME_PACKAGE' must be declared

ليه الناس بتقفز على الصلاحيات؟

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

الخطوات بالتفصيل

1. التأكد من الاسم والسكيمة

مش مجرد "أنا متأكد إن الاسم صح" — لازم تستعلم فعليًا:
SELECT object_name, object_type, status
FROM all_objects
WHERE owner = 'SCHEMA_B'
AND object_name LIKE '%SOME_PACKAGE%';

ليه؟ لأن سيناريوهات زي دي شائعة جدًا: حد نسخ كود من إجراء تاني وغيّر بعض الحاجات بس نسي يغيّر اسم الـ package، أو الاسم كان PKG_SOME_PACKAGE وبقى PKG_SOME_PACKAGE_V2 بعد تحديث، أو حتى فرق بسيط في spelling محدش لاحظه.

2. حالة الكائن (status)

الكائن ممكن يكون موجود بالظبط بنفس الاسم، بس يكون INVALID. ده بيحصل غالبًا لما كائن تاني بيعتمد عليه (dependency) بيتغيّر — زي جدول اتضاف له عمود، أو إجراء تاني جوه نفس الـ package اتعدّل وسبب خطأ compilation. النتيجة: الـ package "موجودة" لكن مش قابلة للاستخدام، والخطأ اللي بيطلع بيشبه مشكلة صلاحيات تمامًا مع إنه مشكلة compilation.

3. تطابق البارامترات

خصوصًا مع الـ packages اللي فيها overloading (نفس اسم الإجراء بس بعدد/نوع بارامترات مختلف)، لو الكود بتاعك بيبعت بارامترات مش متطابقة تمامًا مع أي نسخة من الإجراء، Oracle ممكن يفشل في resolve الاستدعاء بالكامل ويطلع نفس رسالة الخطأ، مش رسالة واضحة تقول "بارامتراتك غلط".

4. الصلاحيات (بعد ما تتأكد من كل اللي فوق)

هنا بس، لو كل حاجة فوق سليمة، تبقى فعلاً مشكلة صلاحيات:
GRANT EXECUTE ON PKG_SOME_PACKAGE TO SCHEMA_A_USER;
CREATE SYNONYM PKG_SOME_PACKAGE FOR SCHEMA_B.PKG_SOME_PACKAGE;

كده الكود بيستدعي PKG_SOME_PACKAGE بس، من غير بادئة، ولو الكائن اتنقل مكانه يومًا (نقلوه لسكيمة تالتة مثلاً)، بتعدّل الـ synonym بس مش كل نقطة استدعاء في الكود كله.

الخلاصة العملية

اتبع الترتيب ده زي checklist، من غير ما تقفز خطوة: اسم → status → بارامترات → صلاحيات → synonym. ده أسرع في المجمل من إنك تخمّن وتمنح صلاحيات عشوائي وتكتشف بعد نص ساعة إن المشكلة كانت حاجة تانية من ال

17/09/2026

رتب افكارك

16/09/2026

من مشاريع APEX بتقع في نفس الغلطة...
بيبدأوا يبنوا شاشات بسرعة، وينسوا أهم سؤال: مين هيدير التعديلات؟
لما الفريق يكبر لـ 5-10 مطورين، هتلاقي نفسك بتدور على:
• نسخة الـ export_2023_final_final2.sql
• مين اللي بوّظ الصفحة؟
• نرجع ازاي؟
APEX دلوقتي عنده كل الحلول، بس لازم تفكر فيها من اليوم الأول.

16/09/2026

الكود بيرجعلك بالظبط قد إيه إنت واضح جوه دماغك

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

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

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

المشكلة إن مبرمجين كتير بياخدوا الدرس ده في اتجاه غلط، بيحسوا إن كل حاجة في الحياة لازم تكون منطقية ومرتبة زي الكود، وده مش دايماً صح، في حاجات في الحياة مش المفروض تتحل زي الباج، مفيش لها "حل صحيح" واحد.

خد الدرس في حدوده الصح: مرة جاية تلاقي نفسك بتكتب كود مبعثر أو معقد أكتر من اللازم، متلومش نفسك على المهارة، اسأل نفسك الأول "أنا فاهم المشكلة دي كويس؟"، غالباً الإجابة هتوجهك أسرع من أي Refactor.

إنت لاحظت إن الكود بتاعك بيبقى مبعثر لما تكون مش فاهم حاجة كويس؟ احكيلي آخر مرة حصل معاك كده.

#برمجة .com

15/09/2026

سؤال بيتجاهله كتير من فرق APEX في بداية أي مشروع كبير: **مين هيدير الكود والتعديلات؟**

في مشروع فيه مطور واحد، الموضوع مش محتاج تخطيط — Export وخلاص.

لكن في نظام فيه 5-10 مطورين شغالين بالتوازي (شاشات، Components، JavaScript، أحيانًا نفس الصفحة)، غياب الإدارة بيبان بسرعة في أسئلة بسيطة تصعب الإجابة عليها:

- مين عدّل إيه؟
- إمتى وليه؟
- لو التعديل بوّظ حاجة، نرجع للنسخة الصح إزاي؟

APEX عنده أدوات فعلية للموضوع دلوقتي: Git integration، Split Export، Working Copies، APEXlang. المشكلة مش في الأدوات — المشكلة إن غالبًا بيتم التفكير فيها متأخر، بعد ما التطبيق يكبر.

القاعدة بسيطة: أي مشروع APEX مؤسسي (ERP أو نظام كبير) لازم تتعامل معاه من أول يوم كمشروع Software له Development Lifecycle حقيقي — مش مجرد شاشات بتتبني بسرعة. الإدارة دي جزء من الـ Architecture، مش خطوة بتضيفها لما تحس إنك محتاجها.

14/09/2026

ليه لسه حاسس إني مش حقيقي

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

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

في علم النفس ده اسمه Impostor Syndrome، وأخطر حاجة فيه مش الإحساس نفسه، الإحساس ده طبيعي وبيحصل لأغلب الناس الناجحة، أخطر حاجة إنه بيخليك تنسب نجاحك لحظ أو ظروف خارجية، وتنسب فشلك (لو حصل) لنقص حقيقي فيك. يعني عقلك بيبقى منحاز ضدك في التفسير، مهما كانت النتيجة.

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

الدرس مش إنك تقنع نفسك إنك "عبقري"، الدرس إنك تاخد الإنجاز زي ما هو، من غير ما تدور على سبب تقلل بيه من قيمته. المرة الجاية لما حاجة تنجح معاك، جرب تسيب الإحساس يكمل لآخره قبل ما عقلك يقولك "بس".

إنت بتحس بالإحساس ده لسه، حتى بعد سنين خبرة؟ احكيلي آخر مرة حصلك.

#برمجة .com

لو الـ AI هيستبدلك، يبقى انت أصلاً كنت بتعمل شغل الـ AI مش شغل المبرمج
13/09/2026

لو الـ AI هيستبدلك، يبقى انت أصلاً كنت بتعمل شغل الـ AI مش شغل المبرمج

12/09/2026

لما حاولت أتحكم في أجينت مالوش قلب

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

وقفت التدريب شوية، مش عشان الموديل غلط، لكن عشان أنا مكنتش قادر أستحمل إن نظام بنيته بإيدي يطلع بردود أنا مش متحكم فيها 100%. وده خلاني أفكر، ده مش أول مرة أحس بالإحساس ده، ده بيتكرر في كل حاجة باعمل فيها، من الـ Database لحد الـ UI، عايز كل تفصيلة تحت سيطرتي بالكامل.

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

بس الأجينت، زي أي نظام ذكاء اصطناعي، مبني على احتمالات مش قواعد ثابتة، هو مش المفروض يطلع نفس الرد بالحرف كل مرة، ده مش عيب فيه، ده طبيعته. والدرس الحقيقي مكنش إزاي أخلي الرد ثابت 100%، الدرس كان إني أفرّق بين "التحكم في الاتجاه العام" و"التحكم في كل كلمة"، أنا محتاج أضبط الإطار والقواعد، مش أحاول أتحكم في كل تفصيلة صغيرة جواه.

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

إنت لاقيت نفسك محتاج تتحكم في حاجة مش المفروض تتحكم فيها بالكامل، سواء في الشغل أو برة؟ إزاي عرفت اللحظة اللي المفروض تسيب فيها؟

#برمجة .com

10/09/2026

الملل مش عدو الإبداع أحسن مبرمج مش اللي بيفضل شغال.. ده اللي بيعرف يبطل🤣🤣
كنت واقف بتتوضأ، مش قاعد قدام لابتوب ولا فاتح ولا سطر كود، وفجأة الحل نط في دماغي. مشكلة كنت متعلق فيها من الضبح من يومين في تكامل بين FastAPI و Oracle، جربت كل حاجة، غيرت في الـ Query، دورت في التوثيق، سألت كل حد، ولا حاجة. وبعدين وأنا بغسل إيدي، من غير أي مقدمات، لقيت نفسي فاهم إن المشكلة مش في الكود، المشكلة في إن الـ Connection Pool مكنش بيتقفل صح قبل ما يتفتح تاني. حاجة بسيطة قوي، بس عقلي مكنش شايفها وأنا قاعد بأركز بجد.

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

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

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

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

إنت جالك حل مشكلة برمجية وانت مش قاعد على الكمبيوتر خالص؟ احكيلي كانت فين وإمتى.

#برمجة #إنتاجية #تكنولوجيا

09/09/2026

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

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

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

الحل مش إنك تبقى "قوي" وتكمل، الحل إنك تدي لنفسك مساحة إنك تبعد بجد عن الشاشة، حتى لو خمس دقايق، تمشي، تشرب مية، تبص لحاجة تانية خالص. العقل مش زي الماكينة، هو محتاج يعيد ترتيب نفسه، ولما ترجع تلاقي إن عينيك شافت حاجة كنت واقف قدامها من ساعتين وملحقتش تشوفها.

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

إنت اتعرضت لإحساس زي ده إمتى؟ وإيه اللي بيساعدك ترجع تركز تاني؟

#برمجة #تكنولوجيا

Address

العنوان: East Lane 340, 340 South 90 Street, New Cairo Governorate (أمام كونكورد بلازا)
Cairo
11865

Telephone

+201270358999

Website

Alerts

Be the first to know and let us send you an email when Hossam Assadallah-حسام اسدالله posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Contact The Business

Send a message to Hossam Assadallah-حسام اسدالله:

Shortcuts

Share

Category