Forwarded from 🚀DevJourney🚀 (Abdulwaisa Al Nuaimi)
شوف… في أشياء لو ما أحد تكلم عنها بوضوح، بتظل تتكرر وتكلفنا كثير بدون ما ننتبه. تخيل معاك نظام أكثر من واحد يستخدمه، وكلهم يشتغلوا على نفس البيانات بنفس الوقت… أنا أشوفها كل مرة: واحد عدّل، والثاني عدّل، وكل واحد يظن إنه اشتغل لحاله، والنتيجة؟ تضارب، بيانات ضاعت، أو أحد كتب فوق الثاني. ولا أحد درى.
وهنا تظهر فكرة يسموها "Optimistic Locking"، بس هي مش مسألة اسم أو مصطلح… هي فكرة ببساطة تقول: "تأكد إنك آخر واحد شاف البيانات قبل ما تغيّر فيها."
يعني بدل ما نقفل البيانات ونمنع الكل يعدل (زي Pessimistic Locking)، نخلي الكل يشتغل بحرية… لكن نحط شرط بسيط: إذا أحد سبقك وعدّل، ما نسمح لك تحفظ إلا لما تشوف التحديث الجديد.
وهذا الشرط البسيط يتم عن طريق شيء يسموه ETag، وهو ببساطة بصمة للبيانات (زي توقيع)، كل مرة يتغير فيها المحتوى، تتغير البصمة.
بالنسبة للتعديل (PUT أو PATCH) لما ترسل الطلب، تحط الهيدر If-Match: "" وتقوله: "أنا بأعدّل، بس فقط لو البصمة هذي نفسها ما تغيّرت." لو تغيّرت؟ السيرفر يرد عليك بـ:
412 Precondition Failed "يعني أحد سبقك وعدّل، لازم تسحب التحديث الجديد وتشوفه أول، بعدين قرر."
والنقطة اللي ناس كثير ما ينتبهوا لها هي حتى عند القراءة (GET) تقدر تحط If-None-Match: "" وهنا تقول للسيرفر: "عطني البيانات فقط لو تغيّرت من آخر مرة." لو ما تغيّرت؟ السيرفر يرد بـ:
304 Not Modified "يعني لا ترجع لي نفس البيانات مرة ثانية، وفر علي البيانات والباندويث."
وش الفايدة؟ فايدتها قوية جدًا في الأنظمة الكبيرة أو اللي فيها بيانات تتكرر كثير. بدل ما كل شوي تجيب نفس البيانات من السيرفر، تستخدم ETag وتخليها كمرجع، وإذا البيانات نفسها؟ السيرفر يقول لك: "مافي جديد"، وأنت ترتاح.
تخيل آلاف الأجهزة تشيك بيانات بنفس اللحظة، لو كلها سحبت البيانات من جديد وهي نفسها؟ ضياع وقت وضغط على السيرفر بلا معنى. لكن مع ETag و If-None-Match؟ تقليل هائل في الاستهلاك، وتحسّن في الأداء، وكل هذا بصمت وذكاء.
والمقارنة هنا مع العكس تمامًا:
لو تجاهلت الـ ETag وفكرت تعدّل بدون أي تحقق، فاحتمال كبير تعدّل على بيانات قديمة بدون ما تدري، والنتيجة: بيانات ضاعت، أخطاء حصلت، أو تقارير صارت فيها تناقضات.
ولو في الـ GET تسحب البيانات في كل مرة بدون ما تسأل إذا تغيّرت؟ يضيع عليك وقت، موارد، وسرعة… والنتيجة تجربة مستخدم بطيئة ومتكررة بدون فائدة.
الخلاصة؟ مش لازم توقف الناس من التعديل، ولا تمنعهم من الوصول، بس خلي بينهم وبين الحقيقة شرط بسيط: "تأكد إنك ما تشتغل على شي قديم."
وهذا الشيء، رغم بساطته، يحل مشاكل كثيرة ويخلي النظام أذكى وأرتب، ويحمي بياناتك من الضياع بصمت.
ونقطة أخيرة… مش كل تعقيد في الكود شر، أحيانًا سطر واحد زي If-Match أو If-None-Match يحميك من أيام من التحقيق في bugs ما حد داري من فين طلعت.
ما تتعامل مع ETag؟ يعني أنت تسحب بيانات "تظن" إنها صحيحة… وتعدل على شيء "تفترض" إنه ما تغيّر… بينما النظام يقول لك: "أنا ما أقدر أضمن لك شيء."
#التزامن_مش_ترف #OptimisticLocking #DotNet #كود_يعيش_طويل #خلي_الكود_يحميك_مش_يعلقك
وهنا تظهر فكرة يسموها "Optimistic Locking"، بس هي مش مسألة اسم أو مصطلح… هي فكرة ببساطة تقول: "تأكد إنك آخر واحد شاف البيانات قبل ما تغيّر فيها."
يعني بدل ما نقفل البيانات ونمنع الكل يعدل (زي Pessimistic Locking)، نخلي الكل يشتغل بحرية… لكن نحط شرط بسيط: إذا أحد سبقك وعدّل، ما نسمح لك تحفظ إلا لما تشوف التحديث الجديد.
وهذا الشرط البسيط يتم عن طريق شيء يسموه ETag، وهو ببساطة بصمة للبيانات (زي توقيع)، كل مرة يتغير فيها المحتوى، تتغير البصمة.
بالنسبة للتعديل (PUT أو PATCH) لما ترسل الطلب، تحط الهيدر If-Match: "" وتقوله: "أنا بأعدّل، بس فقط لو البصمة هذي نفسها ما تغيّرت." لو تغيّرت؟ السيرفر يرد عليك بـ:
412 Precondition Failed "يعني أحد سبقك وعدّل، لازم تسحب التحديث الجديد وتشوفه أول، بعدين قرر."
والنقطة اللي ناس كثير ما ينتبهوا لها هي حتى عند القراءة (GET) تقدر تحط If-None-Match: "" وهنا تقول للسيرفر: "عطني البيانات فقط لو تغيّرت من آخر مرة." لو ما تغيّرت؟ السيرفر يرد بـ:
304 Not Modified "يعني لا ترجع لي نفس البيانات مرة ثانية، وفر علي البيانات والباندويث."
وش الفايدة؟ فايدتها قوية جدًا في الأنظمة الكبيرة أو اللي فيها بيانات تتكرر كثير. بدل ما كل شوي تجيب نفس البيانات من السيرفر، تستخدم ETag وتخليها كمرجع، وإذا البيانات نفسها؟ السيرفر يقول لك: "مافي جديد"، وأنت ترتاح.
تخيل آلاف الأجهزة تشيك بيانات بنفس اللحظة، لو كلها سحبت البيانات من جديد وهي نفسها؟ ضياع وقت وضغط على السيرفر بلا معنى. لكن مع ETag و If-None-Match؟ تقليل هائل في الاستهلاك، وتحسّن في الأداء، وكل هذا بصمت وذكاء.
والمقارنة هنا مع العكس تمامًا:
لو تجاهلت الـ ETag وفكرت تعدّل بدون أي تحقق، فاحتمال كبير تعدّل على بيانات قديمة بدون ما تدري، والنتيجة: بيانات ضاعت، أخطاء حصلت، أو تقارير صارت فيها تناقضات.
ولو في الـ GET تسحب البيانات في كل مرة بدون ما تسأل إذا تغيّرت؟ يضيع عليك وقت، موارد، وسرعة… والنتيجة تجربة مستخدم بطيئة ومتكررة بدون فائدة.
الخلاصة؟ مش لازم توقف الناس من التعديل، ولا تمنعهم من الوصول، بس خلي بينهم وبين الحقيقة شرط بسيط: "تأكد إنك ما تشتغل على شي قديم."
وهذا الشيء، رغم بساطته، يحل مشاكل كثيرة ويخلي النظام أذكى وأرتب، ويحمي بياناتك من الضياع بصمت.
ونقطة أخيرة… مش كل تعقيد في الكود شر، أحيانًا سطر واحد زي If-Match أو If-None-Match يحميك من أيام من التحقيق في bugs ما حد داري من فين طلعت.
ما تتعامل مع ETag؟ يعني أنت تسحب بيانات "تظن" إنها صحيحة… وتعدل على شيء "تفترض" إنه ما تغيّر… بينما النظام يقول لك: "أنا ما أقدر أضمن لك شيء."
#التزامن_مش_ترف #OptimisticLocking #DotNet #كود_يعيش_طويل #خلي_الكود_يحميك_مش_يعلقك
👏2
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
أهمية مراجعة الكود Code Review ستزداد في الفترة المقبلة مع الإعتماد المتزايد على الذكاء الإصطناعي التوليدي.
الوقت الذي نربحه في كتابة الكود بفضل ال AI سيسخر فيما بعد لقراءة ومراجعة وإعادة ترتيب ذلك الكود (قانون انحفاظ الطاقة 😀).
هناك مقولة في عالم البرمجة (منسوبة لمصمم لغة بايثون) تقول أن "الكود يُقرأ أكثر مما يُكتب"، ويبدو لي أنها عبارة سنسمعها أكثر وسيكون لها مسوغات أقوى في المستقبل القريب.
#الموضوع_كبير
الوقت الذي نربحه في كتابة الكود بفضل ال AI سيسخر فيما بعد لقراءة ومراجعة وإعادة ترتيب ذلك الكود (قانون انحفاظ الطاقة 😀).
هناك مقولة في عالم البرمجة (منسوبة لمصمم لغة بايثون) تقول أن "الكود يُقرأ أكثر مما يُكتب"، ويبدو لي أنها عبارة سنسمعها أكثر وسيكون لها مسوغات أقوى في المستقبل القريب.
#الموضوع_كبير
❤1
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
مرحباً،
أبحث عن مطور/ة Frontend مبدع(ة) ومتحمس(ة) للانضمام إلى فريقي لبناء مشروع مفتوح المصدر (Open Source) نطمح من خلاله إلى تقديم منتج عالي الجودة، مبني على أحدث تقنيات وتوجهات البرمجة الحديثة، مع الالتزام بأفضل الممارسات مثل:
كتابة كود نظيف (Clean Code) اتباع مبادئ SOLID استخدام أنماط التصميم (Design Patterns) التعاون ضمن بيئة تقنية تعليمية ومُلهمة
ليش ممكن تكون مهتم؟
ستعمل ضمن فريق يقدّر التعلم وتبادل الخبرات نُولي اهتمامًا كبيرًا بـ مهارات التواصل الفعّال والعمل الجماعي ستُساهم في بناء مشروع حقيقي يُضاف إلى ملفك المهني (Portfolio) ستُطوّر مهاراتك من خلال التطبيق العملي والعمل ضمن فريق محترف المشروع يُدار باحترافية من خلال فترات Sprint محددة، بحيث نراعي وقتك ونوازن بين التعلم والعمل والحياة
هدفنا مو بس ننجز مشروع، بل نبني بيئة حقيقية ننمو فيها كمطورين ونتبادل المعرفة ونتطوّر معاً.
إذا كنت:
تمتلك شغفاً أو خبرة في مجال الـ Frontend تحب التعلم ومشاركة المعرفة تجيد التواصل وتحب العمل ضمن فريق
راسلني، وخلّنا نبدأ سوا رحلة فيها شغف، تطوير، ومساهمة حقيقية في المستقبل.
أبحث عن مطور/ة Frontend مبدع(ة) ومتحمس(ة) للانضمام إلى فريقي لبناء مشروع مفتوح المصدر (Open Source) نطمح من خلاله إلى تقديم منتج عالي الجودة، مبني على أحدث تقنيات وتوجهات البرمجة الحديثة، مع الالتزام بأفضل الممارسات مثل:
كتابة كود نظيف (Clean Code) اتباع مبادئ SOLID استخدام أنماط التصميم (Design Patterns) التعاون ضمن بيئة تقنية تعليمية ومُلهمة
ليش ممكن تكون مهتم؟
ستعمل ضمن فريق يقدّر التعلم وتبادل الخبرات نُولي اهتمامًا كبيرًا بـ مهارات التواصل الفعّال والعمل الجماعي ستُساهم في بناء مشروع حقيقي يُضاف إلى ملفك المهني (Portfolio) ستُطوّر مهاراتك من خلال التطبيق العملي والعمل ضمن فريق محترف المشروع يُدار باحترافية من خلال فترات Sprint محددة، بحيث نراعي وقتك ونوازن بين التعلم والعمل والحياة
هدفنا مو بس ننجز مشروع، بل نبني بيئة حقيقية ننمو فيها كمطورين ونتبادل المعرفة ونتطوّر معاً.
إذا كنت:
تمتلك شغفاً أو خبرة في مجال الـ Frontend تحب التعلم ومشاركة المعرفة تجيد التواصل وتحب العمل ضمن فريق
راسلني، وخلّنا نبدأ سوا رحلة فيها شغف، تطوير، ومساهمة حقيقية في المستقبل.
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
عارف أيش أكبر غلطة ممكن يقع فيها أي مبرمج؟
إنه يحبس نفسه في زاويته ويقول:
"أنا باك إند، ماليش دخل بباقي الفريق!"
أو العكس تمامًا!
الموضوع يبان بسيط بالبداية...
بس أول ما تظهر الـBug، تبدأ لعبة التراشق:
الفرونت يقول: "لاااا، مش من عندي، هذه من الباك إند!"
والباك إند يرد بكل ثقة: "أنا مرجع الـresponse صح، المفروض الفرونت يتعامل معاه!"
والنتيجة؟
Bugs بالمجان، وTesting يتحول لكابوس،
وكل واحد يرمي اللوم على الثاني!
شوف، مش لازم تكون Full-Stack،
بس لازم تكون فاهم الصورة الكبيرة:
من أول ما تبدأ المتطلبات،
مرورًا بالتصميم،
إلى لما نوصل للـTesting...
فهمك لدور كل واحد في الفريق،
وتحديات شغله،
هو اللي بيخليك Developer ناضج ومؤثر.
✔️ لما تطلع لك مشكلة، لا تقول "مش من عندي"،
اسأل فريقك، افهم كيف تأثر عليهم، وساعدهم.
✔️ خذ وقتك تفهم السيستم من أوله لآخره،
حتى لو مش بتشتغل على كل جزء.
✔️ بدل ما ترمي المشكلة، فكر كيف تحلها بأسلوب يخدم الفريق كله.
المشكلة اللي ممكن تجلس يومين رايحة جاية،
ممكن نحلها في 5 دقايق لو اشتغلنا كفريق واحد!
التطوير مش بس بالكود،
التطوير الحقيقي في طريقة تفكيرك وتعاملك مع الناس اللي حواليك.
خلي دايمًا نيتك إنك تكون جزء من الحل، مش من المشكلة.
وهنا فعلاً تبدأ ترتقي كمطور حقيقي.
إنه يحبس نفسه في زاويته ويقول:
"أنا باك إند، ماليش دخل بباقي الفريق!"
أو العكس تمامًا!
الموضوع يبان بسيط بالبداية...
بس أول ما تظهر الـBug، تبدأ لعبة التراشق:
الفرونت يقول: "لاااا، مش من عندي، هذه من الباك إند!"
والباك إند يرد بكل ثقة: "أنا مرجع الـresponse صح، المفروض الفرونت يتعامل معاه!"
والنتيجة؟
Bugs بالمجان، وTesting يتحول لكابوس،
وكل واحد يرمي اللوم على الثاني!
شوف، مش لازم تكون Full-Stack،
بس لازم تكون فاهم الصورة الكبيرة:
من أول ما تبدأ المتطلبات،
مرورًا بالتصميم،
إلى لما نوصل للـTesting...
فهمك لدور كل واحد في الفريق،
وتحديات شغله،
هو اللي بيخليك Developer ناضج ومؤثر.
✔️ لما تطلع لك مشكلة، لا تقول "مش من عندي"،
اسأل فريقك، افهم كيف تأثر عليهم، وساعدهم.
✔️ خذ وقتك تفهم السيستم من أوله لآخره،
حتى لو مش بتشتغل على كل جزء.
✔️ بدل ما ترمي المشكلة، فكر كيف تحلها بأسلوب يخدم الفريق كله.
المشكلة اللي ممكن تجلس يومين رايحة جاية،
ممكن نحلها في 5 دقايق لو اشتغلنا كفريق واحد!
التطوير مش بس بالكود،
التطوير الحقيقي في طريقة تفكيرك وتعاملك مع الناس اللي حواليك.
خلي دايمًا نيتك إنك تكون جزء من الحل، مش من المشكلة.
وهنا فعلاً تبدأ ترتقي كمطور حقيقي.
👍1
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
ليه ممكن تحتاج Message Broker في النظام حقك؟
خلينا نرجع خطوة لورا.
لو إنك تبني web server، كيف بيتعامل مع عدد كبير من الـ requests؟
بيحصل ذا عن طريق إنه يحطهن في queue في الذاكرة،
لأنه لو فتحت thread لكل request، ممكن النظام ما يقدرش يتحمّل العدد الكبير ذا، وكلهن يفشلن (بسبب context switching).
عشان كذا وجود queue بيساعد إنك تتحكم بعدد الـ requests اللي النظام شغّال فيهن بنفس الوقت، والباقي ينتظر دوره في الـ queue.
وطبعًا تقدر تكبّر النظام باستخدام load balancer وتزيد عدد الـ instances، وذا بيخليك تستقبل وتنفذ عدد أكبر من الـ requests،
طالما ما فيش bottlenecks ثانية.
بس إيش المشكلة هنا؟
أولًا، كل ذا داخل الذاكرة، يعني لو حصل restart فجأة، الـ requests اللي في الطابور بتروح.
وثاني حاجة، لسه في حدود للذاكرة حق كل instance،
والـ queue لازم يكون له حجم معيّن عشان تتجنب مشاكل زي memory leak.
ولو امتلى الـ queue، بتبدأ ترفض الـ requests وبتخسرهن.
هنا يجي دور الـ Message Broker، بيقدم لك عدة فوائد:
أولًا، عندك نظام ثاني يضمن إن الرسائل ما تروح، تقدر ترسل الرسالة هناك وتجي تستهلكها وقت ما يكون في thread متاح.
ولو السيرفر حصل له restart، الرسائل تظل موجودة، ما تروح.
ثانيًا، السيرفر حقك يقدر يستقبل الـ request ويرسله للـ message broker،
وهذا أسرع بكثير من تنفيذ الطلب على طول.
وبالتالي تقدر تتعامل مع عدد أكبر من الـ requests بسهولة وتنفذهن لاحقًا.
لكن في أسئلة مهمّة:
كنت ترسل request وتنتظر الرد عشان تعرضه للمستخدم،
الحين بتحتاج تغير هذا الشي، وتستقبل الرد من الـ back-end عن طريق WebSocket أو Server-Sent Events.
هل ممكن الرسائل تروح لو الـ message broker حصل له restart؟
هنا تقدر تضمن إنك تخزن الرسائل بشكل durable،
ومعظم الأنظمة ذي تدعم cluster mode عشان تضمن إنها دايمًا شغّالة (high availability).
هل ضروري أستخدم Message Broker؟
مش دايمًا. في طرق ثانية، مثل إنك تسوي retry من الـ client side،
بس لازم تضمن حاجات زي idempotency وexponential backoff.
لكن الـ message broker بيساعدك كثير لو النظام حقك عليه ضغط كبير جدًا.
كل ذا يعتمد على استخدامك ونوع النظام اللي تبنيه.
لأن استخدام أدوات زي message broker لها فوائد،
لكن كمان فيها تعقيد، من ناحية التكلفة أو الصيانة.
وهو مش حل سحري بيحل لك كل المشاكل.
في مشاكل ثانية بتحتاج تتعامل معها، زي كيف تضمن إن الرسالة وصلت،
أو كيف تحسن الأداء حق الـ consuming، ومشاكل ثانية غيرها.
#البرمجة #تصميم_الأنظمة #MessageBroker #نصائح_للمطورين #هندسة_البرمجيات #برمجة_ويب #أداء_عالي #نظام_موزع #تقنيات_حديثة
خلينا نرجع خطوة لورا.
لو إنك تبني web server، كيف بيتعامل مع عدد كبير من الـ requests؟
بيحصل ذا عن طريق إنه يحطهن في queue في الذاكرة،
لأنه لو فتحت thread لكل request، ممكن النظام ما يقدرش يتحمّل العدد الكبير ذا، وكلهن يفشلن (بسبب context switching).
عشان كذا وجود queue بيساعد إنك تتحكم بعدد الـ requests اللي النظام شغّال فيهن بنفس الوقت، والباقي ينتظر دوره في الـ queue.
وطبعًا تقدر تكبّر النظام باستخدام load balancer وتزيد عدد الـ instances، وذا بيخليك تستقبل وتنفذ عدد أكبر من الـ requests،
طالما ما فيش bottlenecks ثانية.
بس إيش المشكلة هنا؟
أولًا، كل ذا داخل الذاكرة، يعني لو حصل restart فجأة، الـ requests اللي في الطابور بتروح.
وثاني حاجة، لسه في حدود للذاكرة حق كل instance،
والـ queue لازم يكون له حجم معيّن عشان تتجنب مشاكل زي memory leak.
ولو امتلى الـ queue، بتبدأ ترفض الـ requests وبتخسرهن.
هنا يجي دور الـ Message Broker، بيقدم لك عدة فوائد:
أولًا، عندك نظام ثاني يضمن إن الرسائل ما تروح، تقدر ترسل الرسالة هناك وتجي تستهلكها وقت ما يكون في thread متاح.
ولو السيرفر حصل له restart، الرسائل تظل موجودة، ما تروح.
ثانيًا، السيرفر حقك يقدر يستقبل الـ request ويرسله للـ message broker،
وهذا أسرع بكثير من تنفيذ الطلب على طول.
وبالتالي تقدر تتعامل مع عدد أكبر من الـ requests بسهولة وتنفذهن لاحقًا.
لكن في أسئلة مهمّة:
كنت ترسل request وتنتظر الرد عشان تعرضه للمستخدم،
الحين بتحتاج تغير هذا الشي، وتستقبل الرد من الـ back-end عن طريق WebSocket أو Server-Sent Events.
هل ممكن الرسائل تروح لو الـ message broker حصل له restart؟
هنا تقدر تضمن إنك تخزن الرسائل بشكل durable،
ومعظم الأنظمة ذي تدعم cluster mode عشان تضمن إنها دايمًا شغّالة (high availability).
هل ضروري أستخدم Message Broker؟
مش دايمًا. في طرق ثانية، مثل إنك تسوي retry من الـ client side،
بس لازم تضمن حاجات زي idempotency وexponential backoff.
لكن الـ message broker بيساعدك كثير لو النظام حقك عليه ضغط كبير جدًا.
كل ذا يعتمد على استخدامك ونوع النظام اللي تبنيه.
لأن استخدام أدوات زي message broker لها فوائد،
لكن كمان فيها تعقيد، من ناحية التكلفة أو الصيانة.
وهو مش حل سحري بيحل لك كل المشاكل.
في مشاكل ثانية بتحتاج تتعامل معها، زي كيف تضمن إن الرسالة وصلت،
أو كيف تحسن الأداء حق الـ consuming، ومشاكل ثانية غيرها.
#البرمجة #تصميم_الأنظمة #MessageBroker #نصائح_للمطورين #هندسة_البرمجيات #برمجة_ويب #أداء_عالي #نظام_موزع #تقنيات_حديثة
Forwarded from 🚀DevJourney🚀 (Abdulwaisa Al Nuaimi)
هل أبدأ أتعلم TDD؟ ولا أكتب الاختبارات بعدين؟
الصراحة؟ هذا مو السؤال الحقيقي.
السؤال اللي فعلًا لازم تسأله:
هل الكود اللي تكتبه أصلًا قابل للاختبار؟
الموضوع مو عن التوقيت ولا الطريقة.
ناس تمشي مع TDD، وناس تكتب الاختبارات بعد ما تخلص.
بس كل هذا ما يفرق إذا كودك نفسه ما يسمح تنختبره.
خلني أقولك أربع مبادئ إذا فهمتها، بتقدر تختار طريقتك بنفسك، وبتفهم ليش فيه ناس تفضل TDD وناس لا. بتصير كل الطرق منطقية لأنك عرفت الأساس.
1. قلل الآثار الجانبية – Minimise Side Effects
الاختبار يتعقد إذا كودك:
يكتب على الهاردسك
يرسل طلبات HTTP
يتعامل مع الوقت
يتأثر بالبيئة
يعني ببساطة: يعتمد على أشياء ما تقدر تتحكم فيها.
الحل؟ افصل هالجزء عن منطقك، وخله في طبقة خارجية، بحيث تقدر تختبر منطقك بدون ما تدخل في تعقيدات خارجية.
2. اعزل التبعيات – Isolate Dependencies
إذا كلاسك هو اللي ينشئ الأشياء اللي يحتاجها بنفسه، فبتضطر تختبر أشياء مالك دخل فيها.
الحل؟ مرر له التبعيات من برّا، ويفضل تكون عبر Interfaces.
كذا تقدر تسوي لها Mock بسهولة وقت الاختبار.
3. قلل المسؤوليات – Narrow Responsibilities
الميثود اللي تسوي كل شيء؟ مستحيل تختبرها بشكل فعّال.
خلي كل كلاس أو ميثود له مسؤولية واحدة.
الوضوح في الهدف = سهولة في الاختبار.
4. عرف السلوك بوضوح – Define Explicit Behaviours
لا ترجع أشياء غامضة زي true/false بدون سياق.
ولا ترجع object عام وما توضح فيه شيء.
ولا تسوي استثناء وتسكت عليه.
وضح وش تتوقع يصير، وخلي سلوك كودك واضح زي الشمس.
طيب متى نقول عن اختبار إنه "مو اختبار وحدة"؟
مايكل فيذرز قالها بكل وضوح:
"الاختبار لا يعتبر اختبار وحدة (Unit Test) إذا:
تواصل مع قاعدة البيانات
أو مع الشبكة
أو نظام الملفات
أو ما يشتغل مع باقي اختبارات الوحدة في نفس الوقت
أو يحتاج تعديلات على بيئة التشغيل (زي الإعدادات)"
ببساطة: إذا طلع برا الكود واختلط بأشياء خارجية؟ ما عاد اختبار وحدة.
الخلاصة؟
الموضوع ما هو متى تكتب الاختبار.
الموضوع: هل تقدر تختبر كودك أصلاً؟
افهم المبادئ اللي فوق، وصدقني…
وقتها بتعرف الطريق اللي يناسبك بدون ما أحد يقولك وش تسوي.
الاختبار مو هدف.
الاختبار نتيجة طبيعية لكود نظيف ومحترم.
#اختبار_الوحدات #CleanCode #TDD #برمجة #تطوير_البرمجيات #قابلية_الاختبار
الصراحة؟ هذا مو السؤال الحقيقي.
السؤال اللي فعلًا لازم تسأله:
هل الكود اللي تكتبه أصلًا قابل للاختبار؟
الموضوع مو عن التوقيت ولا الطريقة.
ناس تمشي مع TDD، وناس تكتب الاختبارات بعد ما تخلص.
بس كل هذا ما يفرق إذا كودك نفسه ما يسمح تنختبره.
خلني أقولك أربع مبادئ إذا فهمتها، بتقدر تختار طريقتك بنفسك، وبتفهم ليش فيه ناس تفضل TDD وناس لا. بتصير كل الطرق منطقية لأنك عرفت الأساس.
1. قلل الآثار الجانبية – Minimise Side Effects
الاختبار يتعقد إذا كودك:
يكتب على الهاردسك
يرسل طلبات HTTP
يتعامل مع الوقت
يتأثر بالبيئة
يعني ببساطة: يعتمد على أشياء ما تقدر تتحكم فيها.
الحل؟ افصل هالجزء عن منطقك، وخله في طبقة خارجية، بحيث تقدر تختبر منطقك بدون ما تدخل في تعقيدات خارجية.
2. اعزل التبعيات – Isolate Dependencies
إذا كلاسك هو اللي ينشئ الأشياء اللي يحتاجها بنفسه، فبتضطر تختبر أشياء مالك دخل فيها.
الحل؟ مرر له التبعيات من برّا، ويفضل تكون عبر Interfaces.
كذا تقدر تسوي لها Mock بسهولة وقت الاختبار.
3. قلل المسؤوليات – Narrow Responsibilities
الميثود اللي تسوي كل شيء؟ مستحيل تختبرها بشكل فعّال.
خلي كل كلاس أو ميثود له مسؤولية واحدة.
الوضوح في الهدف = سهولة في الاختبار.
4. عرف السلوك بوضوح – Define Explicit Behaviours
لا ترجع أشياء غامضة زي true/false بدون سياق.
ولا ترجع object عام وما توضح فيه شيء.
ولا تسوي استثناء وتسكت عليه.
وضح وش تتوقع يصير، وخلي سلوك كودك واضح زي الشمس.
طيب متى نقول عن اختبار إنه "مو اختبار وحدة"؟
مايكل فيذرز قالها بكل وضوح:
"الاختبار لا يعتبر اختبار وحدة (Unit Test) إذا:
تواصل مع قاعدة البيانات
أو مع الشبكة
أو نظام الملفات
أو ما يشتغل مع باقي اختبارات الوحدة في نفس الوقت
أو يحتاج تعديلات على بيئة التشغيل (زي الإعدادات)"
ببساطة: إذا طلع برا الكود واختلط بأشياء خارجية؟ ما عاد اختبار وحدة.
الخلاصة؟
الموضوع ما هو متى تكتب الاختبار.
الموضوع: هل تقدر تختبر كودك أصلاً؟
افهم المبادئ اللي فوق، وصدقني…
وقتها بتعرف الطريق اللي يناسبك بدون ما أحد يقولك وش تسوي.
الاختبار مو هدف.
الاختبار نتيجة طبيعية لكود نظيف ومحترم.
#اختبار_الوحدات #CleanCode #TDD #برمجة #تطوير_البرمجيات #قابلية_الاختبار
Forwarded from 🚀DevJourney🚀 (Abdulwaisa Al Nuaimi)
🚀DevJourney🚀
هل أبدأ أتعلم TDD؟ ولا أكتب الاختبارات بعدين؟ الصراحة؟ هذا مو السؤال الحقيقي. السؤال اللي فعلًا لازم تسأله: هل الكود اللي تكتبه أصلًا قابل للاختبار؟ الموضوع مو عن التوقيت ولا الطريقة. ناس تمشي مع TDD، وناس تكتب الاختبارات بعد ما تخلص. بس كل هذا ما يفرق إذا…
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
بتشوفوا كثير هالأيام ناس يقولوا "تبني تطبيق كامل في ساعتين أين كان ".
الكلام ذا مش كذب، بس خذوها بعقل.
ما حد قال إنك بتسوي ERP يحل مشاكل المحاسبة وإدارة الموارد، وتخلي أوراكل أو غيرها ترجع بيتها!
الذكاء الاصطناعي يقدر يساعدك تبني تطبيقات، بس بدون خبرة برمجة أو تدخل بشري كبير، اللي بتبنيه بيكون محدود، وسلوكه مش مرن كفاية إنه يشتغل في بيئة إنتاج حقيقية ومعقدة.
الذكاء الاصطناعي بيرفع من إنتاجية المهندسين الفَلاطِحَة بشكل رهيب،
بس ما بيحول أي حد لمهندس يقدر يبني أنظمة ثقيلة ومعقدة، لسه ما وصلنا هناك.
استخدموا عقولكم، هي أغلى نعمة، لا تضيعوها.
الكلام ذا مش كذب، بس خذوها بعقل.
ما حد قال إنك بتسوي ERP يحل مشاكل المحاسبة وإدارة الموارد، وتخلي أوراكل أو غيرها ترجع بيتها!
الذكاء الاصطناعي يقدر يساعدك تبني تطبيقات، بس بدون خبرة برمجة أو تدخل بشري كبير، اللي بتبنيه بيكون محدود، وسلوكه مش مرن كفاية إنه يشتغل في بيئة إنتاج حقيقية ومعقدة.
الذكاء الاصطناعي بيرفع من إنتاجية المهندسين الفَلاطِحَة بشكل رهيب،
بس ما بيحول أي حد لمهندس يقدر يبني أنظمة ثقيلة ومعقدة، لسه ما وصلنا هناك.
استخدموا عقولكم، هي أغلى نعمة، لا تضيعوها.
❤1👍1
الجامعة هي الفرصة الي من خلالها تتعلم أشياء كثيره فستغلها بكل طاقتك كلامي ليس تطلع الأول وتكون تنين الدفعة 💁♂️
👨💻1
Forwarded from 🚀DevJourney🚀 (Abdulwaisa Al Nuaimi)
أهم شي أولًا: خليها تشتغل (First, make it work)
بعدين تقدر تزبط الشكل (Then make it pretty)
ولا تنسى تضيف اختبارات كثير (Add safety with lots of tests) عشان تتأكد إن كل شي تمام.
ابعد عن التعقيد الزايد (Stay away from over-engineering)، خلك بسيط وواضح.
وإذا حسيت الكود يبيله ترتيب؟ عدله ونسّقه (Refactor if needed – and it usually is!)
الـ Refactoring هو السلاح الخفي اللي يخلي كودك نظيف وسهل تتعامل معه.
خلك ذكي، نظّم كودك، واستمتع بالبرمجة!
#يوميات_مبرمج #Refactoring #CleanCode #نصايح_كود #برمجة
بعدين تقدر تزبط الشكل (Then make it pretty)
ولا تنسى تضيف اختبارات كثير (Add safety with lots of tests) عشان تتأكد إن كل شي تمام.
ابعد عن التعقيد الزايد (Stay away from over-engineering)، خلك بسيط وواضح.
وإذا حسيت الكود يبيله ترتيب؟ عدله ونسّقه (Refactor if needed – and it usually is!)
الـ Refactoring هو السلاح الخفي اللي يخلي كودك نظيف وسهل تتعامل معه.
خلك ذكي، نظّم كودك، واستمتع بالبرمجة!
#يوميات_مبرمج #Refactoring #CleanCode #نصايح_كود #برمجة
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
العنوان: "لو كلمت شات جي بي تي، كان حضرلي المحاضرة"
المعيد داخل المحاضرة، ماسك اللابتوب، والشرح شغال كأننا شغالين في جوجل،
وإحنا أصلاً لسه مش عارفين نثبت لينكس!
من سنة أولى لسنة ثالثة، بنتكلم عن أنظمة تشغيل، شبكات، قواعد بيانات، ولغات برمجة.
بس الواقع؟
أنا ما ثبتش لينكس، ولا مرة.
درست PHP، درست Python، بس ولا مرة كتبت كود حقيقي فيهم.
اللي اكتشفته؟
الموضوع مش ملزم!
يعني محدش بيتابع وراك إذا كنت فعلًا طبّقت ولا لأ،
إنت حر... تكتب في التقرير إنك عملت كل حاجة، وهما هيصدقوك.
المعيد بيشرحلك كأنك هتطلع بكرا تبني نظام تشغيل،
وإنت مش عارف تفرق بين CMD و Terminal.
بيطلب منك مشاريع مش بتتناسب مع اللي إنت فهمته أصلًا،
وبيعتبر أي سؤال إضافي "تضييع وقت".
طب لو كلمت شات جي بي تي، يحضرلي المحاضرة؟
أيوه، ويحضرها كمان بفهم، ويشرحلي بعد المحاضرة بمنطق وهدوء.
الجامعة بتقولك: "اللي عايز يتعلم، يتعلم لوحده."
طب ما توريني الطريق الأول؟ ما تديني تجربة حقيقية؟
مش تحفظني أوامر وخليني أكتب كود في Word!
المشكلة مش في المادة... المشكلة في طريقة التدريس، وفي عدم ربط العلم بالحياة.
أنا ما ثبتش لينكس، لكن كتبت في التقرير إني ثبتّه
ما برمجتش بـ PHP، لكن نجحت في المادة.
ليه؟
لأن النظام بيربي طالب بيجيد التمثيل، مش التطبيق.
فـ لو إنت طالب ولسه بتقول "هبدأ لما أخلص المنهج"،
أحب أقولك: المنهج مش هيخلص،
ابدأ من دلوقتي، واشتغل على نفسك بنفسك،
لأن الجامعة مش دايمًا بتعرف تجهزك... لكن أنت تقدر تجهّز نفسك.
المعيد داخل المحاضرة، ماسك اللابتوب، والشرح شغال كأننا شغالين في جوجل،
وإحنا أصلاً لسه مش عارفين نثبت لينكس!
من سنة أولى لسنة ثالثة، بنتكلم عن أنظمة تشغيل، شبكات، قواعد بيانات، ولغات برمجة.
بس الواقع؟
أنا ما ثبتش لينكس، ولا مرة.
درست PHP، درست Python، بس ولا مرة كتبت كود حقيقي فيهم.
اللي اكتشفته؟
الموضوع مش ملزم!
يعني محدش بيتابع وراك إذا كنت فعلًا طبّقت ولا لأ،
إنت حر... تكتب في التقرير إنك عملت كل حاجة، وهما هيصدقوك.
المعيد بيشرحلك كأنك هتطلع بكرا تبني نظام تشغيل،
وإنت مش عارف تفرق بين CMD و Terminal.
بيطلب منك مشاريع مش بتتناسب مع اللي إنت فهمته أصلًا،
وبيعتبر أي سؤال إضافي "تضييع وقت".
طب لو كلمت شات جي بي تي، يحضرلي المحاضرة؟
أيوه، ويحضرها كمان بفهم، ويشرحلي بعد المحاضرة بمنطق وهدوء.
الجامعة بتقولك: "اللي عايز يتعلم، يتعلم لوحده."
طب ما توريني الطريق الأول؟ ما تديني تجربة حقيقية؟
مش تحفظني أوامر وخليني أكتب كود في Word!
المشكلة مش في المادة... المشكلة في طريقة التدريس، وفي عدم ربط العلم بالحياة.
أنا ما ثبتش لينكس، لكن كتبت في التقرير إني ثبتّه
ما برمجتش بـ PHP، لكن نجحت في المادة.
ليه؟
لأن النظام بيربي طالب بيجيد التمثيل، مش التطبيق.
فـ لو إنت طالب ولسه بتقول "هبدأ لما أخلص المنهج"،
أحب أقولك: المنهج مش هيخلص،
ابدأ من دلوقتي، واشتغل على نفسك بنفسك،
لأن الجامعة مش دايمًا بتعرف تجهزك... لكن أنت تقدر تجهّز نفسك.
Forwarded from 🚀DevJourney🚀 (Abdulwaisa Al Nuaimi)
فكرة إنك تضيف بوابة دفع في مشروعك مش حاجة واوو، الفكرة الحقيقية هي: هل انت مستعد تحمي نفسك من الفخاخ اللي جاية بعدها ولا لا؟
تعال نعرف مع بعض رحلة الدفع كيف بتم، وإيش الفخاخ اللي لازم نخلي بالنا منها من بدري. خلينا نمشيها "فخاخ" كذا كأنك ماشي في أرض ألغام!
شوف يا صديقي، العملية ماشية كذا:
تسجل العملية في قاعدة البيانات ترسل الطلب لبوابة الدفع عشان يتم تستلم التأكيد من بوابة الدفع (وهنا تبدأ الفخاخ!)
المحطة الأولى:
تسجيل العملية
أول حاجة تعملها إنك تسجل البيانات هذي عندك:
مين هو العميل؟ المبلغ كم؟ حالة العملية (بانتظار الدفع). تاريخ الطلب.
ليش نسوي كذا؟ لأن البيانات هذي بتكون المرجع لك لما تجي تتأكد من نجاح العملية. ولو نسيتها؟ مبروك عليك المشاكل يا صاحبي!
المحطة الثانية:
إرسال الطلب لبوابة الدفع
هنا الموضوع سهل، السيستم حقك يرسل البيانات لبوابة الدفع، والعميل يدخل بيانات البطاقة أو أي وسيلة دفع ثانية. ذي مش شغلتك، لأن بوابة الدفع هي اللي بتتعامل مع البنك والمشاكل التقنية هناك.
المحطة الثالثة:
استلام التأكيد (وهنا تبدأ الفخاخ!) الفخ الأول: إنك تصدق أي رد من بوابة الدفع!
بوابة الدفع ردت وقالت لك "تم الدفع"، رحت حدثت العملية عندك لـ "مدفوعة"، وسويت كل الخطوات؟ للأسف، ممكن يكون اتنصب عليك!
ليش؟ فيه أدوات مثل Charles Proxy و Burp Suite تخلّي أي أحد يعترض الطلب اللي رايح لبوابة الدفع، ويرد عليك هو، قبل ما يوصل الطلب. فيرسل لك بيانات مزيفة، وانت تصدق إنها حقيقية!
الحل؟ بعد ما توصلك البيانات، لازم ترسل Request ثاني من الباك إند لبوابة الدفع وتتأكد إن العملية فعلًا تمت هناك، مش مجرد أحد يضحك عليك.
الفخ الثاني:
التلاعب في المبلغ
حتى لو تأكدت إن العملية نجحت، انت متأكد إن العميل دفع المبلغ الصحيح؟
ممكن أحد يلعب في البيانات اللي رايحة لبوابة الدفع، مثلًا: اشترى منتج بـ100 دولار، لكن بدل ما توصل البوابة إنها تخصم 100، وصلها إنها تخصم 2 دولار بس!
الحل؟ لما تبعت طلب التأكيد لبوابة الدفع، لا تسأل بس "هل العملية نجحت؟"، لازم تسأل كمان "المبلغ كم؟"، وتقارنه باللي عندك.
الفخ الثالث:
حيلة استرجاع الفلوس (Refund Fraud)
العميل ممكن يدفع، وبعدها يتصل بالبنك ويقول إنه ما كان هو اللي دفع، والبنك يرجع له الفلوس، وانت تخسر! والأسوأ؟
ممكن يدخل يعيد نفس العملية، وانت تخزنها عندك كأنها جديدة، ويرجع يسترجع الفلوس، ويعيد الحركة مرة ثانية وثالثة!
الحل؟
اتأكد إن العملية مازالت pending مش refunded. حدد وقت انتهاء لكل عملية دفع، ولو تأخر الوقت تلغيها تلقائي. اتفق مع بوابة الدفع على حد أدنى للدفع.
الفخ الرابع: تجاهل الـ Webhooks!
بعض المبرمجين يعتمدوا على الرد المباشر من بوابة الدفع، وذا أكبر خطأ!
ليش؟ العميل ممكن يقفل الصفحة قبل ما توصله الاستجابة، أو يصير تأخير في الرد.
الحل؟
اعتمد على Webhooks، اللي هي إشعارات تجيك من بوابة الدفع لما يصير أي تغيير. سيستمك لازم يكون قادر يستقبلها ويتعامل معها صح.
إضافات مهمة ل الشباب:
التعامل مع الـ Idempotency: أحيانًا يصير تأخير أو تكرار في الطلبات، ممكن يسبب تنفيذ العملية مرتين بالخطأ. الحل؟ استخدم Unique Transaction ID، وتأكد ما في معاملة مكررة.
الالتزام بـ PCI DSS Compliance: لو تتعامل مع بيانات البطاقات مباشرة، لازم تلتزم بالمعايير الأمنية، لأن ذا الشي مو خيار، بل إلزامي.
لا تخزن بيانات الكروت عندك نهائيًا. استخدم التوكنز أو Customer IDs اللي توفرها بوابة الدفع.
تأكد إن السيرفر هو اللي يتعامل مع بوابة الدفع، مش الفرونت إند. الـ Signature من بوابة الدفع يضمن إن الرد جاي من عندهم فعلاً، مش مزور، بس مش كافي لحاله. لازم كمان تتأكد إن الـ Transaction ID ما يتكرر، عشان تمنع Replay Attacks.
بالنسبة للفخ الثاني
(التلاعب في المبلغ)، لو قلنا إن الحل هو التأكد من الدفع عن طريق طلب خلفي، طيب ما هو ممكن نفس الشخص يعترض الرد الثاني؟ الحل؟
اعتمد على Webhook أو IPN يجيك مباشرة من بوابة الدفع.
تأكد إن كل Transaction ID يُستخدم مرة وحدة فقط وبمدة محددة.
وفي الأخير خليك دائمًا يقظ، وتأكد إن كل خطوة في الدفع محمية كويس. وصدقني، الأمان في الدفع مش مجرد خطوة، دي رحلة كاملة لازم تكون مستعد لها من البداية للنهاية!
#أمان_الدفع #بوابة_الدفع #تطوير_ويب #حماية_المدفوعات #أمن_المعلومات #المدفوعات_الإلكترونية #مطورين #نصائح_برمجية #تجربة_مطور #فخاخ_الدفع
تعال نعرف مع بعض رحلة الدفع كيف بتم، وإيش الفخاخ اللي لازم نخلي بالنا منها من بدري. خلينا نمشيها "فخاخ" كذا كأنك ماشي في أرض ألغام!
شوف يا صديقي، العملية ماشية كذا:
تسجل العملية في قاعدة البيانات ترسل الطلب لبوابة الدفع عشان يتم تستلم التأكيد من بوابة الدفع (وهنا تبدأ الفخاخ!)
المحطة الأولى:
تسجيل العملية
أول حاجة تعملها إنك تسجل البيانات هذي عندك:
مين هو العميل؟ المبلغ كم؟ حالة العملية (بانتظار الدفع). تاريخ الطلب.
ليش نسوي كذا؟ لأن البيانات هذي بتكون المرجع لك لما تجي تتأكد من نجاح العملية. ولو نسيتها؟ مبروك عليك المشاكل يا صاحبي!
المحطة الثانية:
إرسال الطلب لبوابة الدفع
هنا الموضوع سهل، السيستم حقك يرسل البيانات لبوابة الدفع، والعميل يدخل بيانات البطاقة أو أي وسيلة دفع ثانية. ذي مش شغلتك، لأن بوابة الدفع هي اللي بتتعامل مع البنك والمشاكل التقنية هناك.
المحطة الثالثة:
استلام التأكيد (وهنا تبدأ الفخاخ!) الفخ الأول: إنك تصدق أي رد من بوابة الدفع!
بوابة الدفع ردت وقالت لك "تم الدفع"، رحت حدثت العملية عندك لـ "مدفوعة"، وسويت كل الخطوات؟ للأسف، ممكن يكون اتنصب عليك!
ليش؟ فيه أدوات مثل Charles Proxy و Burp Suite تخلّي أي أحد يعترض الطلب اللي رايح لبوابة الدفع، ويرد عليك هو، قبل ما يوصل الطلب. فيرسل لك بيانات مزيفة، وانت تصدق إنها حقيقية!
الحل؟ بعد ما توصلك البيانات، لازم ترسل Request ثاني من الباك إند لبوابة الدفع وتتأكد إن العملية فعلًا تمت هناك، مش مجرد أحد يضحك عليك.
الفخ الثاني:
التلاعب في المبلغ
حتى لو تأكدت إن العملية نجحت، انت متأكد إن العميل دفع المبلغ الصحيح؟
ممكن أحد يلعب في البيانات اللي رايحة لبوابة الدفع، مثلًا: اشترى منتج بـ100 دولار، لكن بدل ما توصل البوابة إنها تخصم 100، وصلها إنها تخصم 2 دولار بس!
الحل؟ لما تبعت طلب التأكيد لبوابة الدفع، لا تسأل بس "هل العملية نجحت؟"، لازم تسأل كمان "المبلغ كم؟"، وتقارنه باللي عندك.
الفخ الثالث:
حيلة استرجاع الفلوس (Refund Fraud)
العميل ممكن يدفع، وبعدها يتصل بالبنك ويقول إنه ما كان هو اللي دفع، والبنك يرجع له الفلوس، وانت تخسر! والأسوأ؟
ممكن يدخل يعيد نفس العملية، وانت تخزنها عندك كأنها جديدة، ويرجع يسترجع الفلوس، ويعيد الحركة مرة ثانية وثالثة!
الحل؟
اتأكد إن العملية مازالت pending مش refunded. حدد وقت انتهاء لكل عملية دفع، ولو تأخر الوقت تلغيها تلقائي. اتفق مع بوابة الدفع على حد أدنى للدفع.
الفخ الرابع: تجاهل الـ Webhooks!
بعض المبرمجين يعتمدوا على الرد المباشر من بوابة الدفع، وذا أكبر خطأ!
ليش؟ العميل ممكن يقفل الصفحة قبل ما توصله الاستجابة، أو يصير تأخير في الرد.
الحل؟
اعتمد على Webhooks، اللي هي إشعارات تجيك من بوابة الدفع لما يصير أي تغيير. سيستمك لازم يكون قادر يستقبلها ويتعامل معها صح.
إضافات مهمة ل الشباب:
التعامل مع الـ Idempotency: أحيانًا يصير تأخير أو تكرار في الطلبات، ممكن يسبب تنفيذ العملية مرتين بالخطأ. الحل؟ استخدم Unique Transaction ID، وتأكد ما في معاملة مكررة.
الالتزام بـ PCI DSS Compliance: لو تتعامل مع بيانات البطاقات مباشرة، لازم تلتزم بالمعايير الأمنية، لأن ذا الشي مو خيار، بل إلزامي.
لا تخزن بيانات الكروت عندك نهائيًا. استخدم التوكنز أو Customer IDs اللي توفرها بوابة الدفع.
تأكد إن السيرفر هو اللي يتعامل مع بوابة الدفع، مش الفرونت إند. الـ Signature من بوابة الدفع يضمن إن الرد جاي من عندهم فعلاً، مش مزور، بس مش كافي لحاله. لازم كمان تتأكد إن الـ Transaction ID ما يتكرر، عشان تمنع Replay Attacks.
بالنسبة للفخ الثاني
(التلاعب في المبلغ)، لو قلنا إن الحل هو التأكد من الدفع عن طريق طلب خلفي، طيب ما هو ممكن نفس الشخص يعترض الرد الثاني؟ الحل؟
اعتمد على Webhook أو IPN يجيك مباشرة من بوابة الدفع.
تأكد إن كل Transaction ID يُستخدم مرة وحدة فقط وبمدة محددة.
وفي الأخير خليك دائمًا يقظ، وتأكد إن كل خطوة في الدفع محمية كويس. وصدقني، الأمان في الدفع مش مجرد خطوة، دي رحلة كاملة لازم تكون مستعد لها من البداية للنهاية!
#أمان_الدفع #بوابة_الدفع #تطوير_ويب #حماية_المدفوعات #أمن_المعلومات #المدفوعات_الإلكترونية #مطورين #نصائح_برمجية #تجربة_مطور #فخاخ_الدفع
❤2
هات لي هندسة وبيزنس
مش كلها تقنية معلومات
دي لما فكرت اربط بوابة دفع بمشروع التخرج ناهيك عن ربطها في مشاريع سابقه مش فاكرين قوي ذا الجانب طبعا بعد ما تكلمت مع واحد فاهم في هذا الجانب الكلام ده مش من رأسي دا من كلامه لن تحصل الكلام هذا لافي كتب ولا في المريخ الا من ناس جربت فكل الشكر لكل من يعطي من وقته لتوضيح أهم الأشياء الي فعلا ناقصه 🙆
مش كلها تقنية معلومات
دي لما فكرت اربط بوابة دفع بمشروع التخرج ناهيك عن ربطها في مشاريع سابقه مش فاكرين قوي ذا الجانب طبعا بعد ما تكلمت مع واحد فاهم في هذا الجانب الكلام ده مش من رأسي دا من كلامه لن تحصل الكلام هذا لافي كتب ولا في المريخ الا من ناس جربت فكل الشكر لكل من يعطي من وقته لتوضيح أهم الأشياء الي فعلا ناقصه 🙆
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
> لما تسمع معلومة جديدة من صديقك، وماتكون سمعت عنها من قبل، طبيعي جداً إنك تستغرب أو حتى ما تفهمها من أول مرة. بس الغلط الكبير إنك تسكت وتعمل نفسك خبير، كأنك عارف كل شيء من قبل!
صدقني، هالأسلوب يخسّرك كثير. لأنك لما تلبس قناع الفاهم، تحرم نفسك من فرصة حقيقية للتعلم. يمكن صاحبك عنده خبرة، أو مرّ بتجربة، أو قرأ شيء مفيد، ولو سألته وقلت له: "صراحة أول مرة أسمعها، ممكن توضح لي؟" — راح يقدّرك ويحترم فيك رغبتك في الفهم.
لا تخلي الكبرياء يمنعك من إنك تطور نفسك. مافيش إنسان يعرف كل شيء، والعلم عمره ما كان عيب، العيب إنك تتهرب من الفهم علشان ما يبان إنك مش عارف.
خليك دائمًا من النوع اللي يسأل، ويفهم، ويتواضع. التواضع في طلب العلم رفعة، مو نقصان. واللي يسأل اليوم، بكرة يكون هو اللي يُسأل.
صدقني، هالأسلوب يخسّرك كثير. لأنك لما تلبس قناع الفاهم، تحرم نفسك من فرصة حقيقية للتعلم. يمكن صاحبك عنده خبرة، أو مرّ بتجربة، أو قرأ شيء مفيد، ولو سألته وقلت له: "صراحة أول مرة أسمعها، ممكن توضح لي؟" — راح يقدّرك ويحترم فيك رغبتك في الفهم.
لا تخلي الكبرياء يمنعك من إنك تطور نفسك. مافيش إنسان يعرف كل شيء، والعلم عمره ما كان عيب، العيب إنك تتهرب من الفهم علشان ما يبان إنك مش عارف.
خليك دائمًا من النوع اللي يسأل، ويفهم، ويتواضع. التواضع في طلب العلم رفعة، مو نقصان. واللي يسأل اليوم، بكرة يكون هو اللي يُسأل.
Forwarded from الرسمية CS4 Class-22 (أحمد جلال | 𐩱𐩢𐩣𐩵 𐩴𐩡𐩱𐩡)
إذا أنت مبرمج التطبيقات اللي ندوّر عليه،
قدّم على وظيفة App Developer معنا🖱
– مشاريع إبداعية تنشاف وتُستخدم
– بيئة تشجّعك تطوّر وتبدع
– الدوام حضوري في مقر الشركة
– رواتب مجزية
– مقر العمل صنعاء - *#مدري*😁
للتقديم، قم بتعبئة الفورما التالية ⇓
https://forms.gle/wkQ4w3iXCvP7KdQs7
#منقول
قدّم على وظيفة App Developer معنا🖱
– مشاريع إبداعية تنشاف وتُستخدم
– بيئة تشجّعك تطوّر وتبدع
– الدوام حضوري في مقر الشركة
– رواتب مجزية
– مقر العمل صنعاء - *#مدري*😁
للتقديم، قم بتعبئة الفورما التالية ⇓
https://forms.gle/wkQ4w3iXCvP7KdQs7
#منقول
Forwarded from الرسمية CS4 Class-22 (أحمد جلال | 𐩱𐩢𐩣𐩵 𐩴𐩡𐩱𐩡)
يسعدنا في مجموعة هائل سعيد أنعم وشركاه إطلاق برنامج تمهيد - نواة المستقبل للتدريب الصيفي لطلاب وطالبات المستويين الأخيرين في الجامعات اليمنية لمنحهم فرصة التدريب خلال الإجازة الصيفية.
على مدار شهرين، سيوفر البرنامج للمشاركين فرصة فريدة لاكتساب خبرات وتطوير مهاراتهم من خلال التدريب عبر وظائف وشركات مختلفة في مجموعة هائل سعيد أنعم وشركاه. اغتنم هذه الفرصة لتنمية وتعزيز نموك الذاتي من خلال التسجيل في هذا البرنامج المصمم لإطلاق العنان لإمكانيات الجيل القادم. اضغط لمعرفة المزيد والتقديم:
https://careers.hsayemen.com/lp/تمهيد/d6f2094cd85a04d2/?locale=ar_SA
على مدار شهرين، سيوفر البرنامج للمشاركين فرصة فريدة لاكتساب خبرات وتطوير مهاراتهم من خلال التدريب عبر وظائف وشركات مختلفة في مجموعة هائل سعيد أنعم وشركاه. اغتنم هذه الفرصة لتنمية وتعزيز نموك الذاتي من خلال التسجيل في هذا البرنامج المصمم لإطلاق العنان لإمكانيات الجيل القادم. اضغط لمعرفة المزيد والتقديم:
https://careers.hsayemen.com/lp/تمهيد/d6f2094cd85a04d2/?locale=ar_SA
Forwarded from الرسمية CS4 Class-22 (أحمد جلال | 𐩱𐩢𐩣𐩵 𐩴𐩡𐩱𐩡)
اغتنموا الفرصة و سجلوا للتدريب في البرنامج التدريبي التأهيلي الاستثنائي 🔥🔥
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
خير الله واجد
موقع من أفضل المواقع الي استفدت لعمل prototype أصحاب ui/ux
جربته والله ضخم جدا ال free في limit
أتمنى أن يفيدكم ب ai
https://www.visily.ai/
موقع من أفضل المواقع الي استفدت لعمل prototype أصحاب ui/ux
جربته والله ضخم جدا ال free في limit
أتمنى أن يفيدكم ب ai
https://www.visily.ai/
Visily
Visily - AI-powered UI design software
Visily is the UI design software anyone can use. With Visily, you can create hi-fidelity wireframes and prototypes in minutes, all with no learning curve.
👍1
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
تحذير مهم: لا تستخدم الشبكات العامة للإنترنت لمشاركة معلومات حساسة!
هل تعلم أن اتصالك بشبكة Wi-Fi عامة (زي الموجودة في المقاهي أو المولات) ممكن يعرّض بياناتك للخطر؟ خاصة لو دخلت موقع غير آمن (يبدأ بـ http:// بدل https://)!
ليش؟
الشبكات العامة غير مشفّرة، وأي شخص على نفس الشبكة ممكن يتجسس على اتصالك. ممكن يسرق معلوماتك، كلمات المرور، أو حتى بياناتك البنكية باستخدام أدوات بسيطة! والمواقع الغير آمنة ما تقدم أي حماية لبياناتك.
الحل؟
لا تدخل معلوماتك الخاصة في شبكة عامة. لا تستخدم مواقع غير آمنة (تأكد من وجود علامة القفل في المتصفح). استخدم VPN إذا اضطررت للشبكة العامة. أو الأفضل: استخدم باقة الجوال عند الحاجة.
احمِ نفسك، وكن واعيًا في عالم الإنترنت.
هل تعلم أن اتصالك بشبكة Wi-Fi عامة (زي الموجودة في المقاهي أو المولات) ممكن يعرّض بياناتك للخطر؟ خاصة لو دخلت موقع غير آمن (يبدأ بـ http:// بدل https://)!
ليش؟
الشبكات العامة غير مشفّرة، وأي شخص على نفس الشبكة ممكن يتجسس على اتصالك. ممكن يسرق معلوماتك، كلمات المرور، أو حتى بياناتك البنكية باستخدام أدوات بسيطة! والمواقع الغير آمنة ما تقدم أي حماية لبياناتك.
الحل؟
لا تدخل معلوماتك الخاصة في شبكة عامة. لا تستخدم مواقع غير آمنة (تأكد من وجود علامة القفل في المتصفح). استخدم VPN إذا اضطررت للشبكة العامة. أو الأفضل: استخدم باقة الجوال عند الحاجة.
احمِ نفسك، وكن واعيًا في عالم الإنترنت.
👍1
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
"الذكاء الاصطناعي... الطفرة التي جعلتنا نلهث خلف العالم"
عندما بدأ الذكاء الاصطناعي بالانتشار، استفاد منه العالم المتقدم بشكل مذهل. تغيّرت طرق التعليم، وتطورت سُبل العلاج، وتحولت الشركات إلى نماذج أكثر ذكاءً ومرونة.
لكن بالنسبة لبلدان مثل اليمن، كانت الضربة أقسى من أن توصف.
لماذا؟
لأننا لم نكن قد وصلنا بعد إلى المرحلة التي كان فيها الآخرون قبل 10 سنوات، فجاء الذكاء الاصطناعي وقفز فوقنا بعقود. فصرنا لا نلحق فقط، بل نكافح لنفهم ما يحدث.
💔😂
عندما بدأ الذكاء الاصطناعي بالانتشار، استفاد منه العالم المتقدم بشكل مذهل. تغيّرت طرق التعليم، وتطورت سُبل العلاج، وتحولت الشركات إلى نماذج أكثر ذكاءً ومرونة.
لكن بالنسبة لبلدان مثل اليمن، كانت الضربة أقسى من أن توصف.
لماذا؟
لأننا لم نكن قد وصلنا بعد إلى المرحلة التي كان فيها الآخرون قبل 10 سنوات، فجاء الذكاء الاصطناعي وقفز فوقنا بعقود. فصرنا لا نلحق فقط، بل نكافح لنفهم ما يحدث.
💔😂
❤1
Forwarded from InfoTechnology (IT4_2024) (Abdulwaisa Al Nuaimi)
عن تجربه 👇
عند استخدام GitHub، في خيارات مختلفة لتنظيم المشاريع والعمل الجماعي. في البداية، يمكن الواحد يبدأ بريبو في حسابه الشخصي، ويضيف الباقين كمساهمين. لكن مع مرور الوقت، بيواجهوا مشاكل، مثل:
الريبو بيكون مربوط بحساب شخص واحد، يعني لو الشخص هذا غاب أو حذف المشروع، بيضيع كل شيء. ما في صلاحيات واضحة بين الأعضاء، والكل يقدر يعدل أو يمسح من المشروع. الشكل العام للمشروع بيكون فوضوي، ما في هوية ثابتة للفريق أو المشروع.
لكن لو استخدمنا GitHub Organization بدلًا من الريبو الشخصي، الأمور بتتغير:
المشروع بيكون مرتبط باسم الفريق أو الشركة، مو باسم شخص واحد. تقدر توزع الصلاحيات بين الأعضاء بشكل واضح، سواء كانوا مالكين، مشرفين أو مطورين. لو واحد غاب أو خرج من الفريق، المشروع يظل محفوظ وما يتأثر. الشكل العام بيكون أكثر احترافية، وهذا مهم في حالة عرض الشغل أو في السيرة الذاتية.
الفرق بين الريبو الشخصي و Organization: الريبو الشخصي حلو لو بتشتغل لحالك، لكن في حالة العمل الجماعي، الـ Organization هي الخيار الأفضل، لأنها بتمنحك تحكمًا أفضل، وتنظيمًا دقيقًا للصلاحيات، وأمانًا أكبر للمشروع.
أما بالنسبة لـ Azure DevOps: هو قوي ولديه أدوات مفيدة مثل Pipelines و Boards، لكنه بيكون أكثر تعقيدًا في المشاريع الصغيرة. GitHub هو الأنسب في حالة المشاريع الجماعية الصغيرة أو الطلابية.
ولكن إذا كنت بتشتغل مع مجموعة أو على مشروع جماعي، استخدم GitHub Organization لأنه يوفر لك تنظيمًا أفضل وأمانًا للمشروع.
عند استخدام GitHub، في خيارات مختلفة لتنظيم المشاريع والعمل الجماعي. في البداية، يمكن الواحد يبدأ بريبو في حسابه الشخصي، ويضيف الباقين كمساهمين. لكن مع مرور الوقت، بيواجهوا مشاكل، مثل:
الريبو بيكون مربوط بحساب شخص واحد، يعني لو الشخص هذا غاب أو حذف المشروع، بيضيع كل شيء. ما في صلاحيات واضحة بين الأعضاء، والكل يقدر يعدل أو يمسح من المشروع. الشكل العام للمشروع بيكون فوضوي، ما في هوية ثابتة للفريق أو المشروع.
لكن لو استخدمنا GitHub Organization بدلًا من الريبو الشخصي، الأمور بتتغير:
المشروع بيكون مرتبط باسم الفريق أو الشركة، مو باسم شخص واحد. تقدر توزع الصلاحيات بين الأعضاء بشكل واضح، سواء كانوا مالكين، مشرفين أو مطورين. لو واحد غاب أو خرج من الفريق، المشروع يظل محفوظ وما يتأثر. الشكل العام بيكون أكثر احترافية، وهذا مهم في حالة عرض الشغل أو في السيرة الذاتية.
الفرق بين الريبو الشخصي و Organization: الريبو الشخصي حلو لو بتشتغل لحالك، لكن في حالة العمل الجماعي، الـ Organization هي الخيار الأفضل، لأنها بتمنحك تحكمًا أفضل، وتنظيمًا دقيقًا للصلاحيات، وأمانًا أكبر للمشروع.
أما بالنسبة لـ Azure DevOps: هو قوي ولديه أدوات مفيدة مثل Pipelines و Boards، لكنه بيكون أكثر تعقيدًا في المشاريع الصغيرة. GitHub هو الأنسب في حالة المشاريع الجماعية الصغيرة أو الطلابية.
ولكن إذا كنت بتشتغل مع مجموعة أو على مشروع جماعي، استخدم GitHub Organization لأنه يوفر لك تنظيمًا أفضل وأمانًا للمشروع.