الباشمبرمج | Hamed Esam

شوفت ناس كتير أول ما تتعلم يعني إيه Cache، تحط Cache على كل حاجة. أي Request بقى له Cache، أي Response يتحفظ، كأن الكاش حل سحري لكل مشاكل الأداء. بس الحقيقة إن ده غالبًا بيعمل مشاكل أكتر ما بيحل.

ال Cache مش معمول علشان نستخدمة بشكل عشوائي. هو عبارة عن أداة بنستخدمها بذكاء. لو استخدمته في المكان الغلط، هتزود تعقيد المشروع، وتدخل bugs، وتخلي الداتا تطلع قديمة أو غلط.

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

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

7 months ago | [YT] | 26

الباشمبرمج | Hamed Esam

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

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

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

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

الحاجات دي تعتبر أساسيات، بس الأساسيات دي بالذات هي اللي بتفرق بين هاوي ومحترف. المحترف بيبني وهو حاسب حساب الأمان من أول يوم، مش بعد ما المشكلة تحصل!

7 months ago | [YT] | 26

الباشمبرمج | Hamed Esam

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

أول حاجة اختبار ال APIs. أدوات زي Insomnia أو Postman بتخليك تشوف اللي بيحصل فعلًا، مش اللي انت فاكره بيحصل. تجرّب Requests مختلفة، تشوف Responses، تختبر Errors، وتفهم السيستم وهو شغال.

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

إدارة قواعد البيانات محتاجة أدوات محترمة. MongoDB Compass أو DBeaver بيسهّلوا التعامل مع الداتا، قراءة الجداول، تتبع العلاقات، وتنفيذ Queries من غير ما تتوه أو تبوّظ حاجة بالغلط.

وأخيرًا توثيق ال API. التوثيق مش حاجة تتعمل في الآخر ولا شغل ممل. لما التوثيق يبقى تلقائي ومظبوط، أي حد يشتغل معاك يفهم السيستم بسرعة، وانت نفسك لما ترجع للمشروع بعد فترة ما تتوهش.

7 months ago | [YT] | 9

الباشمبرمج | Hamed Esam

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

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

بعد ما تفهم المشكلة، فكر في أبسط حل ممكن. حل بدائي، حتى لو بطيء، وحتى لو مش Optimal. الـ Brute Force مش عيب، ده بداية طبيعية لأي Algorithm محترم. المهم إنك تطلع بفكرة شغالة.

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

لما الفكرة تبقى واضحة، ساعتها تبدأ تفكر في التحسين. إزاي تقلل الوقت؟ إزاي تقلل المساحة؟ هل في Data Structure أحسن؟ هنا بقى بيبدأ التفكير الحقيقي، مش الحفظ.

آخر خطوة هي التنفيذ والاختبار. اكتب الكود، وجرّبه على حالات مختلفة، مش بس المثال اللي في السؤال. الحالات الغريبة والـ Edge Cases هي اللي بتطلع الأخطاء اللي محدش بياخد باله منها.

خليك فاكر دايمًا إن مفيش Algorithm بيطلع Optimized من أول مرة. الحل الصح بيتبني خطوة خطوة، بالتوفيق!

7 months ago | [YT] | 6

الباشمبرمج | Hamed Esam

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

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

بعد كده فكر في أبسط حل ممكن. حل بدائي، حتى لو بطيء، حتى لو مش Optimal. مفيش Algorithm بيتولد جامد من أول مرة. الـ Brute Force مش عيب، ده نقطة بداية.

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

لما الحل يبقى واضح، ساعتها تبدأ تفكر في التحسين. تقلل Time؟ تقلل Space؟ تستخدم Data Structure أحسن؟ هنا بقى بيظهر التفكير الحقيقي، مش الحفظ.

وفي الآخر تيجي مرحلة التنفيذ والاختبار. اكتب الكود، وجرّبه على حالات عادية وغريبة. Edge cases هي اللي بتكشف الغلط مش الحالات السهلة.

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

7 months ago | [YT] | 26

الباشمبرمج | Hamed Esam

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

لو فعلًا عايز تبقى Software Engineer حقيقي، لازم تفهم إن الـ Testing جزء من الشغل نفسه، مش حاجة على الهامش. الكود اللي من غير اختبارات هو كود قابل للكسر في أي وقت، حتى لو شكله تمام دلوقت.

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

الـ Testing بيخليك تكتب كود أحسن من الأساس. لما تبقى عارف إن في Tests هتتحط على الكود، بتفكر أكتر في التصميم، في الحالات الغلط، وفي الحدود اللي ممكن الكود يقع عندها.

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

الخلاصة إن الـ Testing مش تسلية، ومش رفاهية. ده جزء من عقلية الـ Software Engineer. واللي مش مستعد يتعلمه، مهما كان شاطر في الكود، شغله هيفضل ناقص، بالتوفيق !

7 months ago | [YT] | 17

الباشمبرمج | Hamed Esam

ناس كتير بتدخل البرمجة من باب ال Syntax. تتعلم تكتب الكود صح، تحفظ الأوامر، وتعرف ال keywords. وده طبيعي في البداية، ومفيش حد بيعدي المرحلة دي من غير ما يدخلها.

بس مع الوقت بتلاحظ إن الناس اللي بتكبر فعلًا في الشغل، واللي بتستلم سيستمات تقيلة، مش مميّزة لأنها حافظه syntax أكتر. الميزة الحقيقية إنهم فاهمين ال patterns اللي ورا الكود.

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

علشان كده لما تمسك مشروع كبير، هتلاقي حاجات زي Factory و Observer و Singleton و Strategy موجودة بشكل أو بآخر. مش علشان منظرها حلو، لكن لأنها بتحل مشاكل حقيقية في التنظيم، والتوسّع، وغيره.

اللي بيفهم patterns، بيقرأ الكود أسرع، وبيعدّل بثقة، وبيعرف إمتى يستخدم حل بسيط وإمتى محتاج هيكلة أعمق. إنما اللي واقف عند ال Syntax، كل تعديل صغير بيبقى مغامرة.

بالتوفيق

8 months ago | [YT] | 52

الباشمبرمج | Hamed Esam

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

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

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

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

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

الـ logging مش رفاهية. من غيره مش هتعرف تفهم حصل إيه، ولا ليه الرد اتغير، ولا فين الغلط. أي سيستم AI من غير logs هو سيستم أعمى.

وفي الآخر تيجي قيود الاستخدام والتكلفة. الـ rate limits لازم تتحسب، لأن كل request ليها تمن. ولو ما اتظبطتش، التطبيق ممكن يقع في وقت ما فيه users كتير وضغط علي السيرفر، أو الفاتورة تطلع صادمة (ودا غالباً اللي بيحصل).

وبالمختصر المفيد ال AI مش API بتتوصل وخلاص. الـ AI تفكير، وبناء سيستم، وموازنة بين الجودة والأداء والتكلفة. واللي مش فاهم كده، مهما اشتغل بالـ AI، شغله هيفضل سطحي.

بالتوفيق!

8 months ago | [YT] | 25

الباشمبرمج | Hamed Esam

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

الـ Developer تركيزه الأساسي إن الكود يشتغل. المطلوب يتنفذ، والـ feature تطلع، والمشكلة تتحل. وده دور مهم جدًا، ومفيش مشروع ينجح من غيره.

إنما ال Engineer بيبص للصورة الكبيرة قبل ما يبدأ. بيفكر الكود ده هيأثر إزاي على السيستم كله، وهل الاختيار ده مناسب على المدى الطويل ولا لأ. وهل … وهل … لحد بكرا!

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

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

كمان بيحسب الموارد زي RAM و CPU و Network، وبيعرف إن كل request وكل process ليهم تكلفة، حتى لو مش باينة للمستخدم.

وبيفكر في التكلفة من بدري، لأن القرارات التقنية ليها فلوس حقيقية بتتصرف، مش مجرد كود بيتكتب.

وأهم حاجة، بيفكر في scalability. إزاي السيستم يكبر مع الوقت من غير ما ينهار أو تحتاج تعيد بناؤه من الأول.

في الآخر الفرق مش في المسمّى، ولا في عدد اللغات أو frameworks الفرق في العقلية وتسأل نفسك:
هل بتكتب كود يشتغل دلوقت؟
ولا بتبني سيستم يعيش بعدين؟

8 months ago | [YT] | 25

الباشمبرمج | Hamed Esam

كلمتين مهمين بخصوص الـ Backend.

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

الـ Backend البروفيشنال مش الشخص اللي حافظ Laravel أو Node أو Django (أو أي لغة/framework) ، لكن اللي فاهم إزاي يهيكل الـ API صح. فاهم يعني إيه endpoint واضح، ويعني إيه naming مظبوط، ويعني إيه request و response يخدموا المنتج مش يلغبطوه.

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

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

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

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

بالتوفيق.

8 months ago | [YT] | 27