معلومة على السريع:

وصف Search في وسوم Input كالتالي:
```html
```html
<input type='se
arch' />

يقدم لك بعض الوظائف الإضافية للخانة.

#برمجة_ويب
#Web_development

تلميحة سريعة في الجافاسكربت:

يمكن استخدام الـ Default Parameter مباشرة داخل معطيات الـ Function.
في حالة تقديم Parameter غير مناسب أو عدم تقديمه، يتخذ الـ Default Parameter كمعيار أساسي.

#برمجة_ويب
#Web_development

⏹️ من اهم النصائح لتحسين جودة الكود بإذن الله 📚💚

اتباع المبادئ الصلبة
(SOLID Principles)

⬅️ لكتابة كود قابل للتوسع والصيانة بسهولة.

كتابة كود نظيف ومنظم
(Clean Code)

⬅️ حافظ على بساطة الكود واجعل أجزائه مفهومة و واضحة قدر الإمكان.

التوثيق الجيد
(Documentation)

⬅️ قم بكتابة تعليقات توضيحية وتوثيق الأكواد لتسهيل فهمها من قبل الآخرين.

إعادة استخدام الكود
(Code Reusability)

⬅️ اجعل الكود قابل لإعادة الاستخدام من خلال استخدام الدوال والوحدات او الفصول البرمجية.

التنسيق الصحيح للكود
(Code Formatting)

⬅️ اتبع معايير التنسيق الموحدة للكود واستخدم أدوات مثل Prettier وESLint لتحسين تنسيق الكود.

التسمية الواضحة والمتناسقة
(Clear Naming Conventions)

⬅️ استخدم أسماء متناسقة ومعبرة للمتغيرات، والدوال، والوحدات او الفصول البرمجية.

إجراء الاختبارات الدائمة
(Continuous Testing)

⬅️ تأكد من اختبار الكود بانتظام باستخدام وحدات او فصول الاختبار بشكل مستمر لتجنب الأخطاء.

المراجعة الدورية للكود
(Code Reviews)

⬅️ اطلب من زملائك مراجعة كودك بانتظام لتحسين جودته واكتشاف الأخطاء المحتملة.

تقليل التكرار
(Avoid Code Duplication)

⬅️ تجنب تكرار الكود عن طريق استخدام الدوال والوحدات او الفصول البرمجية المشتركة.

تحسين الأداء
(Performance Optimization)

⬅️ حلل أداء الكود وابحث عن طرق لتحسينه مثل تقليل استخدام الذاكرة وتحسين سرعة التنفيذ.

استخدام أنماط التصميم
(Design Patterns)

⬅️ استعن بأنماط التصميم المعروفة مثل Singleton وFactory وObserver لحل المشاكل المتكررة بطرق منظمة وفعالة.

التعلم المستمر
(Continuous Learning)

⬅️ استمر في تعلم أفضل الممارسات والأدوات الجديدة من خلال قراءة الكتب والمستندات والمقالات وحضور الدورات التدريبية سواء كانت حضورية في الواقع او على مواقع تعليمية.

⏺️ تحسين جودة الكود يتطلب الالتزام بالممارسات الجيدة والاستمرار في التعلم والتطوير. باتباع هذه النصائح، ستتمكن من كتابة كود أكثر احترافية وفعالية بإذن الرحمن.

طريقة لطيفة لفهم Timing Functions في css
😅

#css

كاميرات المراقبه الغير قانونيه او ما يقصد بها الكاميرات المتخفية !
هي كاميرات مراقبه بحجم صغير جدآ قد يكون حجمها شبهة لحجم كاميره الهاتف الاماميه والمزودة بتقنيه الوايفاي وتاتي غالبآ مختفيه بين الاشياء اليومية مثل في الاقلام ومنافذ USB ومنافذ الكهرباء واجهزة انذار الدخان والمراوح المنزلية  واجهزة الوايفاي وغيرها ، حيث تقلل من الاشتباه بها مما قد يجعلها كاميرات مراقبه التجسسيه
بمجرد انتهاء المجرمين من تصويرهم غير القانوني، يمكنهم تحميل ملفات اللقطات على خوادمهم لتوزيعها على مواقع البالغين لاحقًا، حجم مقاطع الفيديو المسربة يوميًا مرتفع بشكل مثير للقلق

#لمحة_برمجية

كورس للبش مهندس الزيرو
يشرح برنامج github   بشكل بسيط وكيف ترفع مشاريعك البسيطة  بحيث انك راح ترجع لها في اي وقت
كل ما زادت مشاريعك زادت خبرتك و CV تبعك هذا الذي يتطلبه الواقع .
وهذا الرابط :هنا

هذا فيديو آخر مدته ساعة : هذا الرابط .

#للفائدة

Don't forget

😅😅

الكورس متوفر و منزل جاهز للذي حابب ينسخه و كذلك الفيديو الثاني متوفر.

بإذن الله سيتم توفيرها لكم في مكتب الملتقى للذي حابب يستفيد 🤝🌚

بروكسي لتشغيل تطبيق تليجرام .. للي حصلت له مشاكل بالتطبيق بالأمس

https://news.1rj.ru/str/proxy?server=5.75.183.209&port=9090&secret=FgMBAgABAAH8AwOG4kw63QtY2RueWVrdGFuZXQuY29tZmFyYWthdi5jb212YW4ubmFqdmEuY29tAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

هل فكرت كيف جوجل يشتغل؟

https://www.youtube.com/watch?v=WCpimlH0Kck

+ محتوى sloth جميل جداً ينصح بالاشتراك بقناته على اليوتيوب

#coding

في مشاريع التخرج وفي سوق العمل بشكل عام... بينتهي بنا الأمر بقاعده بيانات ضخمة جداً.. وعشان نفعل التقارير بينتهي بنا الأمر في SQL مشابه لهذا 🙂💔

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

مشكلة الكويري هذا لما البيانات كبيرة انه كان يأخذ وقت تقريباً 2 الى 5 دقائق عشان يشتغل 🤕
هذا اذا كان مجموع الrows الناتجه 100 ألف صف... فكيف لو كان مليون او أكثر!؟

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

كذلك مع أسلوب البارتات سأترك للكم مجال التفكير فقد ربما تجدوا حل أفضل بكثير وتشاركوه للجميع...

#سلسلة #DB

قبل كل شي... لازم نسأل انفسنا هذه الاسئله
1. ايش هو DB؟
هي قاعدة البيانات (Database) عباره عن النظام الذي نستخدمه لحفظ الداتا بطريقة متناسقة في جداول... وعادة الجداول هذه ما بيستفيد منها اليوزر بشكل مباشر ، وانما بيستفيد من جداول معينه تم تجميع البيانات ب كويري معقد...
وهذا صعب تحققه بدون ال view الموجودة في كل db (الي كان د.منتظر يقول لنا نتخيله)
فيعني الجداول فقط اشياء مساعده لنا عشان نقدر نسوي views ونستفيد منها المبرمجين والمستخدمين بشكل كلي.👍


2. ليش view مهم!؟
اي تقرير متوسط وكبير بيكون فيبه joins كثير من ٣ واكثر مثلاً... واذا مافي view في كل مره انت تفعل query بتضطر تكتب sql او orm object بشكل معقد...
ولكن مع الـ View بيساعد في تبسيط هذه العملية بحيث يتم تعريف View لمرة واحدة كاستعلام مجمع ومعقد، وبعدها تقدر تستخدمه كأي جدول آخر في db بواسطة استعلامات بسيطة مثل:

select * from view_name;

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


3. ايش المشكلة طيب 😒!؟
تأخيل معي هذا الكويري (الرسالة الي فوق)
صح هو sql ولكن حتى ولو استخدمت orm برضو ما بتهرب من joins الي في sql 🤕

فهنا المشكلة كانت في performance... وحتى وان عملنا View فللأسف يا عزيزي المبرمج والبرمجة ما بيتم تحسين سرعة الكويري 😔
بالعكس... البعض يقول ان عمل views يزيد يأخر عمل الكويري للأسباب التالية:-
1 - ما تقدر تفعل index لل view
2 - الطبقة الي انت تغلفها الكويري (الي هو ال view) برضو معها كود معين وطريقه معينه للوصول للبيانات... لهذا هي ابطأ من sql العادي الي بدون view
3 - اسباب كثيره الي مهتم بها اسألو Google عليها.


فهنا كيف بيتم التعامل مع هذه المشكلة!!! 🤕
- كيف اكتب كويري بنفس عدد joins
- وبنفس الوقت كيف أحافظ على فكرة view لانه لما أشوف select كل شي من ال view ابسط بكثير لما اقرأ 100 سطر SQL او ORM
- وبنفس الوقت وبدل ما يشتغل بدقيقتين يشتغل ب ٣ ثواني أو أقل !

الحل يا اعزائي بتركه عليكم تفكرو وتحاولو تشاركو الإجابة نشوف من بيحزر الجواب... او في بارت 2 بتشوفوه امامكم
الي يشتي يشارك فكره معينه يرسلها الى يوزري:
@E_1_E

#db #سلسلة

شكرا لكل شخص أهتم وشارك... هذه ملخصات المشاركة...

1- الأخ اسامة دماج قال:
- ليش ما نفعل علاقات M to N بحيث بدل joins يكون في جدول وسيط بينه كل شي
= والله جميل يا اسامه بس هذه لما تكون db بحدود 20 او 30 جدول مثلا... يعني سهل لو ارتفع عدد الجداول +10
ولكن المشكله ال db المذكورة في السلسله عبارة عن db كبيره يمكن أكثر من 80 جدول... وكل جدول يحتوي على علاقات كثيره مع جداول مختلفه... بمعنى قد يرتفع عدد الجداول الى 120 او 150 حتى!!
وهدف ال DB اصلا محاولة تقليل وتنظيم البيانات في اقل عدد ممكن من الجداول عشان المساحه والسرعه 👍

2 - الأخت "السلام الداخلي" والأخ أحمد "ahmed askar" جابو طريقه حلوة:
استخدام ال index وبنفعل view طبيعي وسريع... ولكن نفس الشي في رقم 1... الحل بينفع في حالات معينه... ولكن اذا كان العميل بنك مثلا... فكمية البيانات الهائلة جدا وإن زودنا عدد ال index بنواجه مشاكل ثانيه غير select... لانه في كل مره تسوي insert لبيانات جديده مثلا ، قاعده البيانات بتعيد ترتيب index ولو في بيانات كثيره عمليه الإضافة بتكون بطيئة جدا 🤕

3 - كذلك الأخ أحمد "ahmed askar" أقترح نسوي شي اسمه Materialized Views   وفكرته نفس View ولكن يحفظ النتائج مسبقا... وهنا بصراحه تكلمت اليوم مع موظفين الشركه اشوف رأيهم الخاص ولكن ما زال هناك اختلاف في الأراء بشكل كبير... بس وأقتبس من كلام أحدهم:-

المشكلة ليست ب View او ب Materialized Views وانما بطريقة عمل sql نفسها... فدائما select كل شيء من جدول واحد حتى وان كان الجدول كبير مره وفيبه بيانات كثيره جدا جدا
بيكون أسرع بكثير من select كل شيء من view لنفس البيانات ولكن بجداول منفصله. بسبب join و أخواتها هذا غير إن حصل تعديل في أحد الجداول من اضافه او تعديل او حذف ، فبيتم تشغيل joins من جديد وبيأخذ وقت طويل (ال 5 الدقائق المذكورة في بدايه السلسلة)

المهم... نوقف استقبال الان المشاركات للبارت 1
سيتم نشر البارت الثاني للمشكله مع ذكر طريقه الحل الي في سوق العمل قريباً ان شاء الله 👍

في احد الحسابات علي اللينكدان نزل شويه اسئله انترفيو لل backend هي عموما ل laravel بس غالبيتها يمشي علي الكل يعني معضم الأسئلة تحسها عامة لأنها مصطلحات ومفاهيم عامة بغض النظر عن اللغة او الفريم ورك .

1-اي هو OOP ؟
2- اي الفرق بين session & cookies؟
3- اي الفرق بين class & object؟
4- اي هو template engine في لارافيل
5- اي الفرق construct & destractor و هل استخدمت destractor قبل كدا؟
6- اي الفرق بين class & trait؟
7- اي interface & abstract و استخدمتهم في اي؟
8- اي هي مبادي Solid ؟
9- اي هو sql joins و اي انواعها ؟
10- اي الفرق بين where , groub by , having ؟
11- امتي استخدم sql join و امتي استخدم ORM ؟
12- اي الحالات اللي استخدم فيها sql join ؟
13- اي الفرق بين extend , implment و بنستخدم كل واحدة امتي ؟
14- اي هو event & listeners و استخدامهم في اي ؟
15- اي هو queue & jobs ؟
16- اي هو facade ؟
17- باكدج spatie permessions شغالة ازاي في database ؟
18- اي هو polymorgh ؟
19- اي هيا design battern اللي استخدمتها في شاريعك ؟
20- اي هيا sql injection ؟
21- اي هو dependency injection ؟
22- اي الفرق بين service conainer & service provider ؟
23- اي هيا access modefiers ؟
24- اي الفرق بين self & this ؟
25- امتي بنستخدم single auth & multi auth ؟
26 - اشرح laravel request life cycle ؟
27- اي هيا CSEF ؟
28- لية بنستخدم migration و مش بنتعامل مع data base مباشرة ؟
29- اي الحاجات اللي بتاثر علي performance او سرعة الموقع من حيث الفرونت و الباك ؟
30- اي الفرق بين sql query و query bulder و ORM elequant ؟
31- ال route عبارة عن اي ؟
32- اية هو observer ؟
33- اية هو repositary pattern ؟
34- اية هو N+1 ؟
35- اية هو service layer
36- اية هو x-blade componant ؟
37- اية هو seeder & factory ؟
38- اية هو composer ؟
39- اية هو overloading & overriding ؟
40- اية هو namespace ؟
41- اية هو collection ؟
42- اية هو callback function ؟
43- اية هو transaction ؟
44- اية هو مبادي rest api ؟
45- اي هيا trait ؟
46- اي هو Model Binding ؟
47- ازاي نحسن سرعة Query معين ؟
48- اي ال accessor and mutator ؟
49- يعني اي migration ؟
50- اي الفرق بين http & https ؟
51- اي الفرق بين mysql & oracle ؟
52- اي هو MVC ؟
53- اي config files ؟
54- اي هو throtting ؟
55- اي الفرق بين observer & triggers؟

قد تجد يعض الأسئلة بسيطة وبعضها لأول مره تسمع عنها فلذلك من خلال هذي الأسئلة حاول تبحث وتتعلم الأشياء الذي تلاحظها جديده عليك

📛📛 API (Application Programming Interface)

اولاً عشان نعرف ايش هو الـ API لازم نعرف ايش هو الـ Json

🔹 الـ Json: هي طريقة لكتابة البيانات بطريقة تفهمها كل لغات البرمجة عشان تتواصل وتنقل البيانات من مكان الى آخر

🔹 طيب كيف هذه البيانات بتنتقل؟
هنا يجي دور الـ API
وهو الوسيط بين الـ backend وكل التطبيقات الي تستخدم البيانات الخاصة به (وهنا يمكن يكون في شي مش مفهوم لكن شوية ونفهمه)
والـ API ماهو الا رابط او Link بنستخدمه عشان نعمل request معين من قاعدة البيانات، سواءًا تجيب بيانات مخزنة في القاعدة او ترسل بيانات عشان تتخزن فيها او تحذف او تعدل.

وطبعاً ما نقدر نتواصل مع قاعدة البيانات مباشرة من موقع ويب كواجهات بإستخدام JS او كتطبيق موبايل
لكن بيكون في الـ backend developers هم الي بيتعاملوا مع البيانات ويوصلوا لقاعدة البيانات بلغة مثل php او c#
وكذلك هم الي بيقوموا بعمل الـ API عشان مطورين التطبيقات او الويب كواجهات والخ يقدروا يوصلوا لقاعدة البيانات بالـ API الي يوفروه لنا
ويكون محدد حسب ما يسمحوا به هم وهذا يخلينا نوصل لنقطة...

🔹 ماهي مكونات الـ API

1- الـ base Url
وهذا بيكون ثابت في التطبيق كامل ما يتغيرش ويعبر عن الـ domain الي موجود فيه الاستضافة على السرفر
مثل:

https://www. app. com

2- الـ end point
وهذا بيحدد ايش تشتي توصل له بالضبط وبيتغير طبعاً حسبما الـ backend developers بيحددوه
مثل:

/users

وهذا بيتبع الـ base Url وبيمثل غالباً الجدول الي بتوصل له

3- الـ headers
وهي بيانات بترسلها مع الـ request عشان المطور ممكن يحتاجها عشان يعمل شيء معين او يعرف كيف يرجع لك response حسب هذه البيانات
مثل:

Accepted_Language: ar

وهذا المثال عشان يعرف هل يرجع لك الرد عربي او انجليزي

4- الـ body:
وهنا بترسل بيانات بيتعامل معاها المطور فمثلاً هنا اذا تشتي تدخل بيانات لقاعدة البيانات بترسلها هنا كـ json مثلاً، او تعدل بيانات وغيرها
مثل:

{"Name": "Ahmed"}

5- الـ Query parameters
وهذه محددات بترسلها في ال Url نفسه وتفيد انك تمرر مثلاً الـ id حق المستخدم عشان يفعل الـ query على اساسه بإستخدام الـ Where
مثل:

?id=2

ادوات اختبار الاختراق مع طرق استخدامها

مسابقة اعادة تصميم شعار مطاعم الربيع بقيمة 1000$
المنشور قبل 6 ايام
اخر موعد يوم 26 من هذا الشهر

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

التفاصيل:
https://www.facebook.com/share/p/19SXP8XLxd/

ورجعنا مع بارت 2... طبعا اعذروني على التأخير فهذه الرسائل اكتبها أنا ويأخذ مني وقت.

طبعا الحلول الي شاركوها العيال والبنات سابقاُ فهمنا انها صحيحه لحالات معينه... بس الحاله الي في الشركه مختلف.

نتكلم عن db كبيره جدا مع بيانات عملاقه وعلاقات توجع الدماغ 🤕
ملاحظة: انا أحكي لكم حل الشركة وليس معناته ان هذا أفضل حل ممكن... حلهم جميل في حالتهم الخاصة فقط وقد ربما يكون في طرق أفضل وأسرع
فلا تعتمدو على هذه الطريقه 100%


لما الشركه فكرت بحلول للمشكلة... احد الموظفين جاب فكره حلوه... وقال ليش ما استغل فكره:-
select * from table_name
بدل مسأله :
select * from view_name
بمعنى... ليش المستخدم لما يشتي تقرير معقد يروح يجيبه من view! ليش ما نفعل جدول ثاني نفس view وفيبه 0 علاقات ونروح نجيب الداتا منه!

طيب ليش!؟ مش احنا عارفين ان select من جدول واحد حتى وان كانت بياناته كبيره بيكون أسرع (بشكل ملحوظ) من select مع join لنفس البيانات ولكن بجداول منفصله

ولكن هنا في مشكلة كذلك!
الdb اصلا فوق 80 جدول! فكيف بيتم عمل هذا!!

هنا الشركة عملت db ثانيه عشان ما تعصد ال db الأساسية
والاسم حقها اذا اسم الdb الرئيسي هو
store_db
يكون اسم الdb حق التقارير الكبيرة كمثال:
store_db_big_reports
او اي اسم بدل big reports عشان التنظيم

المهم...
بشرح لكم بشكل مختصر جداً الحل الي تم اتخاذه في الشركة
فكرة db الجديده عباره عن db شبه مؤقته...
بيكون كل جدول فيها يمثل view في قاعده البيانات الأساسية ، بمعنى لو معي مثلا 10 views ولكن في 6 حبات منهن ثقيلااات مره ويتأخرين لما نستعلم منهم... ال db الجديدة بيكون فيها 6 جداول فقط (ما يحتاج لباقي ال view ال 4 لانهن سريعات)

طبعا الحل الي الشركه تستخدمه يكون عمل مشترك من db و backend... ولان اغلبنا سنه 4 بتكلم بالثنتين مع بعض.

طبعا مستحيل يكون الحل بهذه البساطه!! اصلا لازم يتم أخذ هذه الأمور في الحسبان:-
1 - لازم نتأكد ان الثنتين db متزامنات... اي اذا في شي جديد في db الأساسية لايزم ما يكون موجود في db المؤقته حق التقارير العملاقة
2 - لازم ما يكون عملية التحقق هذه تتم بالكود... اي ان العميل او المستخدم ما يحس ان في 2 db ويحصل sync فيما بينهم...
3 - يتم انشاء مشروع جانبي api لكي يدير عمل ال db الجديده - طبعا اذا كان المشروع الأساس مرتب وبتقدر تضيف كل شي فيه فما يحتاج انشاء المشروع الجديد.

الان بعد ما فهمنا بشكل نظري كيف الطريقه عادة يكون بعده دور الكود... ولكن مستحيل اشارك الكود بسبب:
1 - الكود تبع شركه وخاص بها.
2 - الكود طويل جداً.

لهذا بشرح لكم الكود هدره والي يشتي يتعمق يفعل مشروع جانبي ويحاول يطبقه 👍

الان نبدأ نطبق موضوع sync بين الثنتين قواعد البيانات... بس كيف؟! 🤔

ببساطه في db الأساسية ما بيتم تعديل اي شي فيها! فقط بنضيف جدول جديد في db الموقتة فكرته بكل بساطه يفعل لنا track للاشياء الجديده الي تحصل في db الجديدة من insert و delete و update
طبعا مش لكل الجداول... انما للجداول ال 6 حق view المذكورة سابقاً

الهيكلية تبع الجدول الجديد هو:
id, row_id, view_name

وكما هو معروف.. ال id هو pk
ال row_id هذا ال id الخاص بالصف الي تعدل او انضاف او انحذف في db الأساسية
والاخير هو ايش اسم الفيو
ولا تنسو... بيكون هذا الجدور له دور اساسي في طريقه الشركه.

طبعا الان بتقولو فهمنا كل شي... بس في سؤالين
1 - ايش استفدنا من جدول track وكيف بنفعل track?
يا عزيزي بيتم عمل api بين الثنتين... اذا تم اضافه او تعديل او حذف اي صف في أي جدول بيتم ارسال request الى api وبيضيفه هناك في track... ومن ثم بشرح لكم كيف تتعاملو مع الجدول لما يكون فيبه داتا 👍
2 - ال db الجديده ايش بيكون فيها غير هذا الجدول؟!
بيكون كل view في db الأساسية عباره عن جدول جديد في db الجديده
بمعنى انه جدول عادي بدون اي علاقه نفس view ولكنه create table بدون ما يكون joins

فيعني اذا معي 6 views ثقيله مره بيكون معي 6 جداول اساسيه هناك فقط وانتهينا

هنا بتوقف... هل انتهينا من الشرح؟! لا 🤕
في بارت 3 بواصل اشرح لكم طريقه الحل مع تلميحات في الكود...

أترك لكم مجال مشاركة ارائكم وافكاركم ان اردتم وكعادة المنشور السابق... يوزري:-
@E_1_E
#db #سلسلة

#Sql in one paper

HTTPS VS HTTP

يحتاج مطور الـFrontend إلى التأكد من ملائمة الصفحات التي ينفذها على جميع الشاشات .. من فترة قريبة اكتشفت برنامج Responsively
وهو أداة تساعدك على معاينة اي موقع على أكثر من قياس بنفس الوقت وبسهولة

#Front_End