Zum Inhalt springen

Arabic:تطوير تطبيقات الويب

Aus MOOCsWiki Staging
Version vom 29. August 2026, 11:58 Uhr von Glanz (Diskussion | Beiträge) (aiMOOC über GPT aiMOOC Action erstellt)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
aiMOOC-Siegel

تطوير تطبيقات الويب



مقدمة

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

يستهدف المقرر طلبة الجامعات والمتعلمين في التعليم العالي ممن لديهم معرفة أولية بالبرمجة والمنطق الخوارزمي. لا يفترض المقرر إتقان إطار عمل بعينه؛ فالهدف هو فهم المبادئ التي تبقى صالحة عند الانتقال بين تقنيات الواجهة الأمامية والخلفية المختلفة. ستستخدم أمثلة بلغة HTML وCSS وJavaScript، وستقرأ أمثلة SQL، وتتعامل مع واجهات API، وتربط هذه العناصر ضمن بنية تطبيق كاملة.

شعار HTML5
يمثل HTML البنية الدلالية الأساسية لمحتوى صفحات الويب.


أهداف التعلم

  1. تمييز أدوار المتصفح والواجهة الأمامية والخادم وقاعدة البيانات في تطبيق ويب حديث.
  2. بناء واجهات دلالية باستخدام HTML وتنسيقها بتخطيطات متجاوبة في CSS وإضافة السلوك التفاعلي باستخدام JavaScript.
  3. تصميم واجهات API واضحة تتعامل مع الطلبات والاستجابات وحالات الخطأ بصورة قابلة للاختبار.
  4. نمذجة البيانات العلائقية وكتابة استعلامات آمنة وفهم دور الفهارس والمعاملات والقيود.
  5. تطبيق مبادئ الإتاحة والأمن منذ مرحلة التصميم بدل إضافتها بعد اكتمال المنتج.
  6. إعداد مسار اختبار ونشر يراعي الأسرار البرمجية والهجرات والمراقبة وإمكان التراجع عن إصدار معيب.


بنية تطبيق الويب ومسار الطلب

عندما تكتب عنوانًا أو تضغط زرًا في تطبيق ويب، يبدأ تفاعل بين عدة طبقات. المتصفح مسؤول عن عرض الواجهة وتنفيذ JavaScript، بينما يستقبل الخادم طلبات HTTP أو HTTPS ويطبق منطق الأعمال، وقد يستدعي خدمات أخرى أو يقرأ من قاعدة بيانات. فصل المسؤوليات يجعل النظام أسهل في الاختبار والصيانة والتوسع.

يمكن تمثيل بنية شائعة على النحو الآتي:

المستخدم
   ↓
المتصفح والواجهة الأمامية
   ↓ طلب HTTPS
واجهة API
   ↓
منطق التطبيق
   ↓
طبقة الوصول إلى البيانات
   ↓
قاعدة البيانات

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

مخطط يوضح علاقة العميل بالخادم
يوضح نموذج العميل والخادم؛ يبدأ العميل الطلب ويرسل الخادم الاستجابة.

في HTTP يتكون الطلب عادة من طريقة مثل GET أو POST ومسار ورؤوس وجسم اختياري. أما الاستجابة فتتضمن رمز حالة ورؤوسًا وجسمًا قد يكون HTML أو JSON أو ملفًا آخر. افهم رموز الحالة بوصفها عقدًا بين العميل والخادم: نجاح الطلب ليس هو نفسه إنشاء مورد جديد، والخطأ في الإدخال ليس هو نفسه غياب الصلاحية أو عدم وجود المورد.

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


الواجهة الأمامية: HTML وCSS وJavaScript

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

شعار CSS3
تستخدم CSS لوصف العرض والتخطيط والاستجابة لمقاسات العرض المختلفة.
شعار غير رسمي للغة JavaScript
تضيف JavaScript السلوك التفاعلي وتتعامل مع واجهات الويب والطلبات الشبكية.

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

<main>
  <h1>لوحة المقررات</h1>
  <form id="course-search" aria-label="البحث في المقررات">
    <label for="query">كلمة البحث</label>
    <input id="query" name="query" type="search" required>
    <button type="submit">بحث</button>
  </form>
  <section id="results" aria-live="polite"></section>
</main>

مثال CSS متجاوب: يسمح Grid ببناء تخطيط يتكيف تلقائيًا مع العرض المتاح، كما أن الخصائص المنطقية مثل margin-inline أنسب للواجهات متعددة الاتجاهات.

:root {
  --space: 1rem;
  --card-min: 16rem;
}

.course-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(var(--card-min), 1fr));
  gap: var(--space);
  margin-inline: auto;
  max-width: 72rem;
}

button:focus-visible,
input:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
}

@media (prefers-reduced-motion: reduce) {
  * {
    scroll-behavior: auto;
    transition-duration: 0.01ms;
  }
}

مثال JavaScript لاستهلاك API: عالج أخطاء الشبكة وحالات HTTP، ولا تفترض أن كل استجابة ناجحة. وعند إدراج نص قادم من الخادم في الصفحة، فضّل textContent بدل بناء HTML من سلاسل غير موثوقة.

const form = document.querySelector("#course-search");
const results = document.querySelector("#results");

form.addEventListener("submit", async (event) => {
  event.preventDefault();
  const query = new FormData(form).get("query");

  try {
    const response = await fetch(`/api/courses?query=${encodeURIComponent(query)}`);
    if (!response.ok) throw new Error("فشل الطلب");

    const payload = await response.json();
    results.replaceChildren();

    for (const course of payload.data) {
      const item = document.createElement("p");
      item.textContent = course.title;
      results.append(item);
    }
  } catch (error) {
    results.textContent = "تعذر تحميل النتائج. حاول مرة أخرى.";
  }
});

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


التصميم المتجاوب والإتاحة

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

رمز يوضح التصميم المتجاوب
التصميم المتجاوب يكيّف الواجهة مع أحجام العرض والأجهزة المختلفة.

الإتاحة جزء من جودة البرمجيات. ابدأ بعناصر HTML الأصلية مثل button وlabel وnav قبل اللجوء إلى أدوار ARIA. حافظ على ترتيب منطقي للتركيز، وتأكد من إمكانية تشغيل الواجهة بلوحة المفاتيح، وقدّم نصًا بديلًا مفيدًا للصور ذات المعنى، ولا تعتمد على اللون وحده لنقل حالة أو خطأ. يجب أن يبقى المحتوى مفهومًا عند التكبير، وأن تكون رسائل التحقق مرتبطة بحقولها، وأن يكون التباين مناسبًا.

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

يمكنك استخدام المبادئ الأربعة الشائعة في إرشادات إتاحة محتوى الويب كعدسة مراجعة: هل المحتوى قابل للإدراك؟ هل التشغيل ممكن بوسائل إدخال مختلفة؟ هل التفاعل مفهوم ومتوقع؟ وهل البنية قوية بما يكفي للعمل مع تقنيات مساعدة مختلفة؟

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


الواجهة الخلفية وواجهات API

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

يمكن تصور تدفق الطلب كالتالي:

طلب العميل
   ↓
موجّه الطلبات
   ↓
التحقق من المدخلات
   ↓
المصادقة والتفويض
   ↓
منطق الأعمال
   ↓
مستودع البيانات
   ↓
استجابة موحدة

واجهة API الجيدة توثق الموارد والمدخلات والمخرجات والأخطاء. في تصميم قائم على HTTP، غالبًا ما تستخدم GET للقراءة وPOST للإنشاء وPUT أو PATCH للتعديل وDELETE للحذف، مع الانتباه إلى معنى كل طريقة وخصائصها. يجب ألا يعتمد العميل على نص رسالة الخطأ وحده؛ الأفضل توفير رمز حالة مناسب وبنية JSON ثابتة قدر الإمكان.

مخطط يوضح طلبًا إلى واجهة API واستجابة بصيغة JSON
يوضح نمطًا مبسطًا لطلب العميل بيانات من واجهة ويب وإعادة الخادم استجابة منظمة.

مثال لبنية استجابة JSON:

{
  "data": [
    { "id": 17, "title": "هندسة الويب" }
  ],
  "meta": {
    "page": 1,
    "pageSize": 20
  }
}

مثال لمسار خلفي بصياغة JavaScript تعليمية: يوضح المثال التحقق من المعرف وفصل الوصول إلى البيانات عن طبقة HTTP.

app.get("/api/courses/:id", async (req, res) => {
  const id = Number(req.params.id);

  if (!Number.isInteger(id) || id <= 0) {
    return res.status(400).json({ error: "معرف غير صالح" });
  }

  const course = await courseRepository.findById(id);
  if (!course) {
    return res.status(404).json({ error: "المورد غير موجود" });
  }

  return res.status(200).json({ data: course });
});

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


قواعد البيانات ونمذجة البيانات

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

مخطط يوضح النموذج العلائقي للجداول
يوضح فكرة تنظيم البيانات في جداول مترابطة ضمن نموذج علائقي.

مثال SQL مبسط:

CREATE TABLE courses (
  id BIGINT PRIMARY KEY,
  title VARCHAR(200) NOT NULL,
  published BOOLEAN NOT NULL DEFAULT FALSE
);

CREATE TABLE enrollments (
  course_id BIGINT NOT NULL,
  student_id BIGINT NOT NULL,
  enrolled_at TIMESTAMP NOT NULL,
  PRIMARY KEY (course_id, student_id),
  FOREIGN KEY (course_id) REFERENCES courses(id)
);

CREATE INDEX idx_enrollments_student
ON enrollments(student_id);

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

عند استقبال قيمة من المستخدم، لا تبن استعلام SQL بدمج النصوص. استخدم الاستعلامات المعلّمة أو المحضّرة التي ترسل الشيفرة والقيم في قنوات منفصلة. هذا يقلل خطر حقن SQL ويجعل معالجة الأنواع أوضح.

مثال آمن من حيث المبدأ:

const result = await db.query(
  "SELECT id, title FROM courses WHERE id = $1",
  [courseId]
);


الأمن والخصوصية في تطبيقات الويب

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

الحقن البرمجي: تجنب تحويل مدخلات غير موثوقة إلى أوامر. استخدم استعلامات معلّمة لقواعد البيانات، واستخدم واجهات DOM الآمنة مثل textContent، وطبّق الترميز المناسب في سياق العرض.

المصادقة والجلسات: استخدم كلمات مرور مخزنة بتجزئة مخصصة لكلمات المرور، ولا تخزن كلمة المرور نفسها. اجعل ملفات تعريف الارتباط الحساسة مناسبة للسياق مع خصائص مثل Secure وHttpOnly وSameSite عندما تنطبق، وحدد فترات انتهاء معقولة، وأبطل الجلسات عند الأحداث الحساسة.

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

النقل الآمن: استخدم HTTPS لحماية البيانات أثناء انتقالها بين العميل والخادم. لكنه لا يحمي تلقائيًا من أخطاء منطق الصلاحيات أو من تسرب أسرار داخل السجل أو المستودع البرمجي.

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

التسجيل والمراقبة: سجّل أحداثًا تساعد في التحقيق والأداء من دون تسجيل كلمات المرور أو الرموز الحساسة أو بيانات شخصية لا تحتاجها. افصل رسائل الخطأ الموجهة للمستخدم عن التفاصيل الداخلية التي يحتاجها فريق التطوير.


الاختبار والأداء والنشر

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

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

خط نشر نموذجي:

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

مثال Dockerfile تعليمي مختصر: شغّل العملية بامتيازات أقل متى أمكن، ولا تنسخ الأسرار إلى الصورة.

FROM node:lts-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY . ./
USER node
CMD ["node", "server.js"]

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


مشروع تكاملي: من المتصفح إلى الإنتاج

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

يمكن تلخيص تدفق تسجيل طالب في مقرر هكذا:

زر التسجيل
   ↓
تحقق الواجهة من الحقول
   ↓
POST إلى API عبر HTTPS
   ↓
تحقق الخادم من الجلسة والصلاحية
   ↓
معاملة في قاعدة البيانات
   ↓
إنشاء التسجيل أو إرجاع تعارض واضح
   ↓
تحديث الواجهة ورسالة حالة قابلة للإدراك

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


مهام تفاعلية


اختبار: اختبر معرفتك

ما الدور الأساسي لـ HTML في الواجهة الأمامية؟ (وصف بنية المحتوى ومعناه) (!تشفير حركة الشبكة) (!إدارة فهارس قاعدة البيانات) (!تخزين أسرار الخادم)




لماذا يجب أن يعيد الخادم التحقق من المدخلات حتى لو تحققت منها الواجهة؟ (لأن طلبات العميل يمكن تعديلها خارج الواجهة) (!لأن CSS لا يعمل مع النماذج) (!لأن قاعدة البيانات لا تخزن النصوص) (!لأن HTTPS يمنع إرسال النماذج)




أي أسلوب أفضل لإضافة نص غير موثوق إلى صفحة باستخدام JavaScript؟ (استخدام textContent) (!بناء سلسلة HTML وتشغيلها) (!تحويل النص إلى أمر JavaScript) (!تخزين النص في ملف إعدادات سري)




ما الفائدة الأساسية من تخطيط CSS مرن يعتمد على Grid وminmax؟ (التكيف مع مساحة العرض المتاحة) (!تشفير كلمات المرور) (!إنشاء جداول قاعدة البيانات) (!إلغاء الحاجة إلى HTML الدلالي)




ماذا يعني رمز الحالة 404 في API بصورة نموذجية؟ (المورد المطلوب غير موجود) (!تم إنشاء المورد بنجاح) (!يجب تشفير قاعدة البيانات) (!تم منح المستخدم صلاحية إدارية)




ما الفرق الصحيح بين المصادقة والتفويض؟ (المصادقة تثبت الهوية والتفويض يحدد الصلاحيات) (!المصادقة تنسق CSS والتفويض ينفذ JavaScript) (!المصادقة تنشئ الفهارس والتفويض يحذفها) (!لا يوجد فرق وظيفي بينهما)




ما الغرض من المفتاح الأساسي في جدول علائقي؟ (تمييز كل سجل بصورة فريدة) (!ضغط صور الواجهة) (!تحديد لون الروابط) (!تشفير بروتوكول HTTP)




أي ممارسة تقلل خطر حقن SQL؟ (استخدام استعلامات معلّمة بالقيم) (!دمج مدخل المستخدم مباشرة في نص SQL) (!إخفاء زر الإرسال باستخدام CSS) (!تعطيل السجلات التشغيلية بالكامل)




ما العبارة الصحيحة عن CORS؟ (هو سياسة متصفح ولا يحل محل المصادقة والتفويض) (!هو خوارزمية لتجزئة كلمات المرور) (!هو قاعدة بيانات موزعة) (!هو بديل عن HTTPS)




ما المكان الأنسب عادة لأسرار الإنتاج مثل كلمة مرور قاعدة البيانات؟ (نظام إدارة أسرار أو إعدادات بيئة محمية) (!ملف JavaScript المرسل إلى المتصفح) (!تعليق داخل مستودع الشفرة العام) (!قيمة ثابتة داخل HTML)





لعبة الذاكرة

HTML وصف البنية الدلالية لمحتوى الصفحة
CSS تحديد العرض والتخطيط والاستجابة للشاشات
JavaScript إضافة السلوك التفاعلي والمنطق في المتصفح
API عقد منظم للتواصل بين مكونات برمجية
HTTPS قناة HTTP محمية بالتشفير أثناء النقل
DOM تمثيل برمجي لشجرة عناصر الوثيقة





السحب والإفلات

طابق المفهوم مع الوصف الصحيح. المعنى في تطوير الويب
المصادقة إثبات هوية المستخدم
التفويض تحديد العمليات المسموح بها لهوية مثبتة
الاستعلام المعلّم تمرير قيم البيانات منفصلة عن نص SQL
التصميم المتجاوب تكييف التخطيط مع خصائص مساحة العرض
نقطة نهاية API مسار يستقبل نوعًا محددًا من طلبات الخدمة
خط النشر سلسلة آلية من الفحوص والبناء والاختبارات والإصدار





كلمات متقاطعة

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





مهام مفتوحة


سهل

  1. صفحة HTML دلالية: أنشئ صفحة عربية لمقرر جامعي تستخدم main وnav وsection وform وlabel، ثم اشرح في فقرة قصيرة لماذا اخترت كل عنصر دلالي.
  2. شبكة CSS متجاوبة: صمم شبكة بطاقات تتكيف من الهاتف إلى الشاشة الواسعة باستخدام Grid ووحدات مرنة وخصائص منطقية مناسبة لاتجاه العربية.
  3. فحص إتاحة واجهة: اختر صفحة تجريبية وافحصها بلوحة المفاتيح والتكبير وأسماء الحقول، ثم دوّن خمس ملاحظات عملية مع إصلاح مقترح لكل ملاحظة.
  4. استهلاك واجهة API: اكتب JavaScript يرسل طلب GET إلى API تجريبية ويعرض النتائج باستخدام textContent مع معالجة حالة فشل واضحة للمستخدم.


متوسط

  1. تصميم API للمقررات: صمم نقاط نهاية لإنشاء المقررات وقراءتها وتعديلها وحذفها، وحدد الطرق وحالات الاستجابة وبنية الأخطاء في جدول صغير.
  2. مخطط قاعدة بيانات جامعية: ارسم مخطط كيان وعلاقة لطلاب ومقررات وتسجيلات، ثم حدد المفاتيح الأساسية والخارجية والقيود التي تمنع التسجيل المكرر.
  3. مراجعة نموذج دخول آمن: ابن نموذج تسجيل دخول تجريبيًا ثم اكتب تقريرًا يوضح التحقق من المدخلات وإدارة الجلسة ورسائل الخطأ وما يجب ألا يُسجل في السجلات.
  4. اختبار تكاملي لمسار تسجيل: أنشئ اختبارًا يرسل طلب تسجيل طالب في مقرر ويتحقق من الاستجابة ومن تغير قاعدة البيانات ومن معالجة حالة التسجيل المكرر.


متقدم

  1. تطبيق ويب كامل: نفذ تطبيقًا صغيرًا لإدارة المقررات بواجهة متجاوبة وAPI وقاعدة بيانات، وأرفق مخطط بنية يوضح انتقال الطلب من المتصفح إلى التخزين والعودة.
  2. مراجعة أمنية منهجية: أنشئ نموذج تهديد لتطبيقك وحدد الأصول والحدود والتهديدات والإجراءات الوقائية، ثم راجع مخاطر الحقن والجلسات والصلاحيات والأسرار.
  3. خط نشر آلي: صمم خط CI وCD يتضمن الفحص والاختبار والبناء وهجرة قاعدة البيانات والنشر التدريجي والمراقبة وخطة التراجع، وفسر شروط الانتقال بين المراحل.
  4. دراسة أداء وإتاحة: قس زمن تحميل صفحة ومسار API ثم نفذ تحسينين قابلين للقياس، وبعد ذلك أعد اختبار لوحة المفاتيح والتكبير واكتب تقريرًا يقارن النتائج قبل التحسين وبعده.





مجالات تعلم مرتبطة

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


مسرد

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


مشروعات aiMOOC

MOOCwiki · Deutsch

Nach dem Lernen ist vor dem Lernen

Entdecke direkt den nächsten Lernkurs. Weitere Inhalte erscheinen, wenn Du weiter nach unten scrollst.

Zur MOOCwiki-Hauptseite

Mediathek

Mediathek

Inhalte werden geladen ...

Mediathek wird aus dem Wiki geladen ...