ما تقوله هو فكرة ممتازة وتندرج تحت مفهوم Infrastructure as Code (IaC)، مع تبسيط وإدخال لغات برمجة مألوفة مثل C# بدلاً من التعامل المباشر مع YAML أو لغات مخصصة مثل Terraform أو Bicep. في الحقيقة، هناك بعض الأدوات التي تسعى لتحقيق هذا الهدف، منها:
1. Pulumi
Pulumi يسمح لك بكتابة الكود المطلوب لإدارة البنية التحتية باستخدام لغات برمجة مألوفة مثل C# أو Python أو TypeScript بدلاً من YAML أو HCL. تقوم Pulumi بترجمة الكود البرمجي إلى الصيغة المطلوبة خلال وقت التشغيل، مع إمكانية إدارة الموارد السحابية بشكل مباشر.
2. CDK (Cloud Development Kit)
أمازون AWS تقدم CDK الذي يمكنك من كتابة كود البنية التحتية باستخدام لغات مثل TypeScript أو Python أو C# بدلاً من كتابة ملفات JSON أو YAML مباشرة.
3. Custom Workflow Generators
يمكنك كتابة Generator خاص بك باستخدام C# مثلاً. يعمل كودك على إنتاج ملفات YAML تلقائيًا من تعريفات مكتوبة بكود C#. الفكرة تشبه كتابة Template Engine يحول المنطق البرمجي إلى ملفات YML جاهزة للتشغيل.
مزايا الفكرة
سهولة الفهم: إذا كنت مرتاحًا أكثر مع C#، يمكنك استخدامه لكتابة التعريفات.
إعادة الاستخدام: يمكنك كتابة مكونات قابلة لإعادة الاستخدام بدلًا من تكرار النصوص YAML.
الاختبار البرمجي: تسهُل عملية اختبار الكود قبل إنشاء الموارد.
خطوات أولية لتنفيذ فكرتك
1. كتابة مكتبة لتحويل C# إلى YAML:
استخدم مكتبة مثل YamlDotNet لتحويل الكود إلى ملفات YAML.
2. تطبيق الموارد:
اجعل الكود يدير إنشاء الموارد باستخدام CLI خاص بـ Docker أو Kubernetes أو غيرها.
3. إدارة البنية التحتية:
استخدم خدمات إدارة البنية التحتية السحابية مثل Azure أو AWS SDKs لدعم تطبيق الموارد مباشرة.
مثال بسيط لتحويل كود C# إلى YAML:
using YamlDotNet.Serialization;
using System.IO;
public class Workflow
{
public string Name { get; set; }
public Job[] Jobs { get; set; }
}
public class Job
{
public string JobName { get; set; }
public string[] Steps { get; set; }
}
class Program
{
static void Main(string[] args)
{
var workflow = new Workflow
{
Name = "My Workflow",
Jobs = new[]
{
new Job { JobName = "Build", Steps = new[] { "dotnet build", "dotnet test" } }
}
};
var serializer = new SerializerBuilder().Build();
var yaml = serializer.Serialize(workflow);
File.WriteAllText("workflow.yml", yaml);
}
}
عند التشغيل، سيتم توليد ملف workflow.yml يمكن استخدامه في أدوات CI/CD مثل GitHub Actions.
1. Pulumi
Pulumi يسمح لك بكتابة الكود المطلوب لإدارة البنية التحتية باستخدام لغات برمجة مألوفة مثل C# أو Python أو TypeScript بدلاً من YAML أو HCL. تقوم Pulumi بترجمة الكود البرمجي إلى الصيغة المطلوبة خلال وقت التشغيل، مع إمكانية إدارة الموارد السحابية بشكل مباشر.
2. CDK (Cloud Development Kit)
أمازون AWS تقدم CDK الذي يمكنك من كتابة كود البنية التحتية باستخدام لغات مثل TypeScript أو Python أو C# بدلاً من كتابة ملفات JSON أو YAML مباشرة.
3. Custom Workflow Generators
يمكنك كتابة Generator خاص بك باستخدام C# مثلاً. يعمل كودك على إنتاج ملفات YAML تلقائيًا من تعريفات مكتوبة بكود C#. الفكرة تشبه كتابة Template Engine يحول المنطق البرمجي إلى ملفات YML جاهزة للتشغيل.
مزايا الفكرة
سهولة الفهم: إذا كنت مرتاحًا أكثر مع C#، يمكنك استخدامه لكتابة التعريفات.
إعادة الاستخدام: يمكنك كتابة مكونات قابلة لإعادة الاستخدام بدلًا من تكرار النصوص YAML.
الاختبار البرمجي: تسهُل عملية اختبار الكود قبل إنشاء الموارد.
خطوات أولية لتنفيذ فكرتك
1. كتابة مكتبة لتحويل C# إلى YAML:
استخدم مكتبة مثل YamlDotNet لتحويل الكود إلى ملفات YAML.
2. تطبيق الموارد:
اجعل الكود يدير إنشاء الموارد باستخدام CLI خاص بـ Docker أو Kubernetes أو غيرها.
3. إدارة البنية التحتية:
استخدم خدمات إدارة البنية التحتية السحابية مثل Azure أو AWS SDKs لدعم تطبيق الموارد مباشرة.
مثال بسيط لتحويل كود C# إلى YAML:
using YamlDotNet.Serialization;
using System.IO;
public class Workflow
{
public string Name { get; set; }
public Job[] Jobs { get; set; }
}
public class Job
{
public string JobName { get; set; }
public string[] Steps { get; set; }
}
class Program
{
static void Main(string[] args)
{
var workflow = new Workflow
{
Name = "My Workflow",
Jobs = new[]
{
new Job { JobName = "Build", Steps = new[] { "dotnet build", "dotnet test" } }
}
};
var serializer = new SerializerBuilder().Build();
var yaml = serializer.Serialize(workflow);
File.WriteAllText("workflow.yml", yaml);
}
}
عند التشغيل، سيتم توليد ملف workflow.yml يمكن استخدامه في أدوات CI/CD مثل GitHub Actions.
نعم، كلا الطريقتين شائعتان وتعتمدان على فلسفة تصميم المشروع واحتياجاته. دعنا نوضح كل طريقة مع مميزاتها وعيوبها:
---
1. بناء الـ Business Domain أولاً
الخطوات: تبدأ بتصميم الطبقة المسؤولة عن منطق العمل (Domain Layer)، بما في ذلك الكيانات (Entities)، الخدمات (Services)، وقواعد العمل (Business Rules).
المميزات:
تركيز على القيم الأساسية: يتيح التركيز على منطق العمل الأساسي دون التأثر بالتفاصيل التقنية.
المرونة: يمكنك بسهولة تبديل أو تحديث طبقات أخرى (مثل Infrastructure) لاحقًا.
تطبيق DDD (Domain-Driven Design): تتماشى هذه الطريقة مع ممارسات DDD التي تركز على منطق العمل كمحور رئيسي.
العيوب:
قد يتطلب المزيد من الجهد في البداية لتحديد المتطلبات بدقة.
صعوبة التحقق من صحة منطق العمل إذا لم تكن البنية التحتية جاهزة.
---
2. بناء الـ Infrastructure أولاً
الخطوات: تبدأ ببناء قاعدة البيانات، واجهات API، والطبقات التقنية (Infrastructure Layer) مثل إدارة البيانات، والاتصالات بالخدمات الخارجية.
المميزات:
سهولة البدء: يمكنك رؤية نتائج العمل سريعًا من خلال واجهات أو قواعد بيانات جاهزة.
دعم التطوير السريع (Rapid Prototyping): يمكن إنشاء نموذج مبدئي لعرضه على الأطراف المعنية.
مفيد عند التعامل مع تكنولوجيا جديدة: إذا كان المشروع يعتمد بشكل كبير على تقنية أو نظام خارجي.
العيوب:
خطر بناء بنية تحتية قد لا تتناسب مع منطق العمل النهائي.
قد يؤدي إلى تصميم أقل مرونة، لأن التركيز يبدأ على التقنية بدلًا من منطق العمل.
---
أفضل الممارسات:
إذا كان المشروع كبيرًا ومعقدًا: يفضل البدء بـ Business Domain أولاً مع استخدام أسلوب DDD.
إذا كنت تعمل على نموذج مبدئي (Prototype) أو مشروع بسيط: يمكن أن تبدأ بالـ Infrastructure.
الدمج بين الطريقتين:
يمكن تطوير أجزاء من منطق العمل والبنية التحتية بالتوازي.
استخدم TDD (Test-Driven Development) لضمان التوافق بين الطبقات.
ما الأنسب لمشروعك؟
---
1. بناء الـ Business Domain أولاً
الخطوات: تبدأ بتصميم الطبقة المسؤولة عن منطق العمل (Domain Layer)، بما في ذلك الكيانات (Entities)، الخدمات (Services)، وقواعد العمل (Business Rules).
المميزات:
تركيز على القيم الأساسية: يتيح التركيز على منطق العمل الأساسي دون التأثر بالتفاصيل التقنية.
المرونة: يمكنك بسهولة تبديل أو تحديث طبقات أخرى (مثل Infrastructure) لاحقًا.
تطبيق DDD (Domain-Driven Design): تتماشى هذه الطريقة مع ممارسات DDD التي تركز على منطق العمل كمحور رئيسي.
العيوب:
قد يتطلب المزيد من الجهد في البداية لتحديد المتطلبات بدقة.
صعوبة التحقق من صحة منطق العمل إذا لم تكن البنية التحتية جاهزة.
---
2. بناء الـ Infrastructure أولاً
الخطوات: تبدأ ببناء قاعدة البيانات، واجهات API، والطبقات التقنية (Infrastructure Layer) مثل إدارة البيانات، والاتصالات بالخدمات الخارجية.
المميزات:
سهولة البدء: يمكنك رؤية نتائج العمل سريعًا من خلال واجهات أو قواعد بيانات جاهزة.
دعم التطوير السريع (Rapid Prototyping): يمكن إنشاء نموذج مبدئي لعرضه على الأطراف المعنية.
مفيد عند التعامل مع تكنولوجيا جديدة: إذا كان المشروع يعتمد بشكل كبير على تقنية أو نظام خارجي.
العيوب:
خطر بناء بنية تحتية قد لا تتناسب مع منطق العمل النهائي.
قد يؤدي إلى تصميم أقل مرونة، لأن التركيز يبدأ على التقنية بدلًا من منطق العمل.
---
أفضل الممارسات:
إذا كان المشروع كبيرًا ومعقدًا: يفضل البدء بـ Business Domain أولاً مع استخدام أسلوب DDD.
إذا كنت تعمل على نموذج مبدئي (Prototype) أو مشروع بسيط: يمكن أن تبدأ بالـ Infrastructure.
الدمج بين الطريقتين:
يمكن تطوير أجزاء من منطق العمل والبنية التحتية بالتوازي.
استخدم TDD (Test-Driven Development) لضمان التوافق بين الطبقات.
ما الأنسب لمشروعك؟
Forwarded from الرسمية CS4 Class-22 (أحمد جلال | 𐩱𐩢𐩣𐩵 𐩴𐩡𐩱𐩡)
📢 مطلوب مبرمج (متميز) في
الاوراكل 11g
و ديفلوبر 6i
Forms & Reports
الراتب بعد المقابلة
للتواصل 777264107
الاوراكل 11g
و ديفلوبر 6i
Forms & Reports
الراتب بعد المقابلة
للتواصل 777264107
Microsoft has released its own document parser for LLM use!
.
.
Introducing MarkItDown, a 100% open-source, one-stop solution for effortlessly converting any file to Markdown—perfect for text analysis, indexing, and more!
Here’s what makes it special:
↳ Converts PDF, Word, Excel, PPT, images, audio to markdown
↳ Extracts EXIF, OCR, and trannoscripts automatically
↳ Available via CLI, Python API, or Docker
↳ Offers LLM-based image denoscriptions
↳ Supports batch conversions
مايكروسوفت أطلقت أداتها الخاصة لتحليل المستندات للاستخدام مع نماذج اللغة الكبيرة (LLM)!
.
.
Introducing MarkItDown
أداة مفتوحة المصدر 100% لتحويل أي ملف بسهولة إلى تنسيق Markdown - مثالية لتحليل النصوص، الفهرسة، والمزيد!
ما الذي يميزها؟
↳ تحويل PDF، Word، Excel، PPT، الصور، والصوتيات إلى Markdown
↳ استخراج بيانات EXIF، OCR، والنصوص تلقائيًا
↳ متوفرة عبر CLI، Python API، أو Docker
↳ تقدم أوصافًا للصور باستخدام LLM
↳ تدعم التحويلات المجمعة
.
.
Introducing MarkItDown, a 100% open-source, one-stop solution for effortlessly converting any file to Markdown—perfect for text analysis, indexing, and more!
Here’s what makes it special:
↳ Converts PDF, Word, Excel, PPT, images, audio to markdown
↳ Extracts EXIF, OCR, and trannoscripts automatically
↳ Available via CLI, Python API, or Docker
↳ Offers LLM-based image denoscriptions
↳ Supports batch conversions
مايكروسوفت أطلقت أداتها الخاصة لتحليل المستندات للاستخدام مع نماذج اللغة الكبيرة (LLM)!
.
.
Introducing MarkItDown
أداة مفتوحة المصدر 100% لتحويل أي ملف بسهولة إلى تنسيق Markdown - مثالية لتحليل النصوص، الفهرسة، والمزيد!
ما الذي يميزها؟
↳ تحويل PDF، Word، Excel، PPT، الصور، والصوتيات إلى Markdown
↳ استخراج بيانات EXIF، OCR، والنصوص تلقائيًا
↳ متوفرة عبر CLI، Python API، أو Docker
↳ تقدم أوصافًا للصور باستخدام LLM
↳ تدعم التحويلات المجمعة
|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|
| Don't Push To Production On Friday |
|＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿|
\ (•◡•) /
\ /
——
| |
|_ |_
| Don't Push To Production On Friday |
|＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿|
\ (•◡•) /
\ /
——
| |
|_ |_
😇2
Forwarded from اللجنة العلمية CS 22 (خالد العبسي)
إذا بتبدأ بمجال الأمن السيبراني وماعندك إمكانية للشهائد العالمية أنصحك تبدأ من هنا الدورة مجانية والحلو إن في تحديد مستوى
الرابط
الرابط
Netacad
Junior Cybersecurity Analyst
This pathway is a series of courses and resources focused on protecting computerized systems and prepares you for a career in cybersecurity.
"أركز على الـ Unit Test ولا الـ Integration Test وخلاص؟"
السؤال هذا يشغل بال كثير من الناس، لكن دعونا نبسط الموضوع بشوية أمثلة عشان تتضح الفكرة.
أولًا: ما هو Unit Test؟
تخيل إنه "المجهر" الذي يكبر لك جزء صغير جدًا من الكود، مثل Function أو Class واحدة.
هدفه الأساسي هو التأكد من أن هذا الجزء يعمل كما هو متوقع لوحده.
مميزاته:
✅ سرعة عالية: يمكن تنفيذ مئات الاختبارات في وقت قصير جدًا.
✅ الكشف المبكر عن الأخطاء: تكتشف الأخطاء بدري، مما يقلل من تأثيرها.
✅ سهولة التعديل: لو الكود تغيّر، تحديث التستات عادة ما يكون بسيطًا.
عيوبه:
❌ غير شامل: ما يهمه إذا كان الجزء الصغير متوافق مع باقي النظام أم لا.
❌ الواقع مش دايمًا مطابق: أحيانًا تحتاج لعمل Mocking كثير، وهذا قد لا يعكس الواقع الحقيقي في البيئة الفعلية.
طيب، ما هو Integration Test؟
لو اعتبرنا أن الـ Unit Test هو "المجهر"، فالـ Integration Test هو "النظرة الشاملة".
هنا يتم اختبار كيف تتفاعل الأجزاء المختلفة مع بعضها.
مميزاته:
✅ واقعية أكبر: يعطيك تصورًا قريبًا لما سيحدث في البيئة الحقيقية.
✅ تقليل المفاجآت: يمنع الأخطاء الناتجة عن عدم توافق المكونات.
عيوبه:
❌ بطيء: لأنك تختبر أجزاء كبيرة مع بعضها.
❌ معقد في الصيانة: إذا حدثت مشكلة، تحديد مصدرها قد يكون صعبًا.
❌ لا يغطي كل السيناريوهات: غالبًا يتم التركيز على التدفقات الحرجة فقط.
طيب، أعمل إيش؟
الموضوع ما هو "Unit أو Integration" فقط، هو مزيج وتوازن.
الخطة:
1️⃣ ابدأ بالـ Unit Tests:
ركز على الأجزاء الصغيرة مثل دوال الحساب أو Checks معينة.
غطِّ الأساسيات عشان تقلل الأخطاء قبل ما تتراكم.
2️⃣ بعدها أضف الـ Integration Tests:
اختبر التدفقات الحرجة مثل تسجيل الدخول أو الدفع.
تأكد أن المكونات تعمل بتناغم.
3️⃣ في المشاريع الصغيرة أو لو فيه استعجال:
ركز بالبداية على الـ Integration Tests لأنها تقلل المخاطر بسرعة.
لاحقًا، أضف Unit Tests لزيادة الثقة بالنظام.
الخلاصة:
لا تعتمد على نوع واحد فقط، اجمع بين الاثنين بما يتناسب مع حجم مشروعك وأهدافك.
كما نقول عندنا في الصنعانية: "التوازن هو أساس النجاح". 🌟
السؤال هذا يشغل بال كثير من الناس، لكن دعونا نبسط الموضوع بشوية أمثلة عشان تتضح الفكرة.
أولًا: ما هو Unit Test؟
تخيل إنه "المجهر" الذي يكبر لك جزء صغير جدًا من الكود، مثل Function أو Class واحدة.
هدفه الأساسي هو التأكد من أن هذا الجزء يعمل كما هو متوقع لوحده.
مميزاته:
✅ سرعة عالية: يمكن تنفيذ مئات الاختبارات في وقت قصير جدًا.
✅ الكشف المبكر عن الأخطاء: تكتشف الأخطاء بدري، مما يقلل من تأثيرها.
✅ سهولة التعديل: لو الكود تغيّر، تحديث التستات عادة ما يكون بسيطًا.
عيوبه:
❌ غير شامل: ما يهمه إذا كان الجزء الصغير متوافق مع باقي النظام أم لا.
❌ الواقع مش دايمًا مطابق: أحيانًا تحتاج لعمل Mocking كثير، وهذا قد لا يعكس الواقع الحقيقي في البيئة الفعلية.
طيب، ما هو Integration Test؟
لو اعتبرنا أن الـ Unit Test هو "المجهر"، فالـ Integration Test هو "النظرة الشاملة".
هنا يتم اختبار كيف تتفاعل الأجزاء المختلفة مع بعضها.
مميزاته:
✅ واقعية أكبر: يعطيك تصورًا قريبًا لما سيحدث في البيئة الحقيقية.
✅ تقليل المفاجآت: يمنع الأخطاء الناتجة عن عدم توافق المكونات.
عيوبه:
❌ بطيء: لأنك تختبر أجزاء كبيرة مع بعضها.
❌ معقد في الصيانة: إذا حدثت مشكلة، تحديد مصدرها قد يكون صعبًا.
❌ لا يغطي كل السيناريوهات: غالبًا يتم التركيز على التدفقات الحرجة فقط.
طيب، أعمل إيش؟
الموضوع ما هو "Unit أو Integration" فقط، هو مزيج وتوازن.
الخطة:
1️⃣ ابدأ بالـ Unit Tests:
ركز على الأجزاء الصغيرة مثل دوال الحساب أو Checks معينة.
غطِّ الأساسيات عشان تقلل الأخطاء قبل ما تتراكم.
2️⃣ بعدها أضف الـ Integration Tests:
اختبر التدفقات الحرجة مثل تسجيل الدخول أو الدفع.
تأكد أن المكونات تعمل بتناغم.
3️⃣ في المشاريع الصغيرة أو لو فيه استعجال:
ركز بالبداية على الـ Integration Tests لأنها تقلل المخاطر بسرعة.
لاحقًا، أضف Unit Tests لزيادة الثقة بالنظام.
الخلاصة:
لا تعتمد على نوع واحد فقط، اجمع بين الاثنين بما يتناسب مع حجم مشروعك وأهدافك.
كما نقول عندنا في الصنعانية: "التوازن هو أساس النجاح". 🌟
AOT vs. JIT: حماية الكود بجانب الأداء 💻🔒
خلينا نتكلم شوية عن موضوع الحماية والجانب الجميل جدًا من AOT .
في C# النقاش بين AOT (Ahead of Time) و JIT (Just in Time) غالبًا بيكون عن الأداء. لكن فيه جانب مهم جدًا لـ AOT وهو: حماية الكود الخاص بك ومنع أي حد من أنه يقدر يطلع عليه. غالبًا الكود بيكون فيه License، والمستخدم يقدر يطلع عليها بسهولة، ويغير فيها كمان، ويعمل Crack للنظام بمنتهى السهولة! وهنا يجي دور من أدوار AOT.
JIT (Just In Time):
في JIT، الكود بيتحول لـ Intermediate Language (IL) اللي بيشتغل على .NET Runtime.
✅ المميزات:
عملية الـ Building بتكون أسرع بكثير من المعتاد.
❌ العيوب:
كود IL ممكن يتفك بسهولة باستخدام أدوات زي ILSpy أو dotPeek، وده بيعرض كود النظام للاختراق.
AOT (Ahead of Time):
في AOT، الكود بيتحول لـ Native Machine Code أثناء عملية البناء (Build)، وده بيكون مخصص للمنصة وصعب جدًا يتم عكسه.
✅ المميزات:
أمان الكود: المخرجات بتكون Native Binary، وده بيصعب عملية فك الكود (Decompiling).
سرعة في تشغيل التطبيق (Startup Time).
❌ العيوب:
دعم محدود للميزات الديناميكية زي الـ Reflection.
عملية الـ Build بتاخد وقت أطول.
ليه تستخدم AOT للحماية؟
لو حماية كود النظام أو الملكية الفكرية أولوية بالنسبة لك، AOT بيوفر طبقة إضافية من الأمان ضد الهندسة العكسية. صحيح مش حماية 100%، لكنه أكثر أمانًا بكتير من كود IL الناتج عن JIT.
أمتى تستخدم كل واحد؟
AOT:
لما الأمان وسرعة التشغيل تكون عوامل رئيسية.
النظام يكون داخلي وغير معرض للعمل على أنواع مختلفة من أنظمة التشغيل.
JIT:
لما تحتاج مرونة وتحسين أثناء التشغيل.
مناسب للتطبيقات Server-Side الكبيرة.
قرارك سيعتمد على احتياجات المشروع. دمتم سالمين.
خلينا نتكلم شوية عن موضوع الحماية والجانب الجميل جدًا من AOT .
في C# النقاش بين AOT (Ahead of Time) و JIT (Just in Time) غالبًا بيكون عن الأداء. لكن فيه جانب مهم جدًا لـ AOT وهو: حماية الكود الخاص بك ومنع أي حد من أنه يقدر يطلع عليه. غالبًا الكود بيكون فيه License، والمستخدم يقدر يطلع عليها بسهولة، ويغير فيها كمان، ويعمل Crack للنظام بمنتهى السهولة! وهنا يجي دور من أدوار AOT.
JIT (Just In Time):
في JIT، الكود بيتحول لـ Intermediate Language (IL) اللي بيشتغل على .NET Runtime.
✅ المميزات:
عملية الـ Building بتكون أسرع بكثير من المعتاد.
❌ العيوب:
كود IL ممكن يتفك بسهولة باستخدام أدوات زي ILSpy أو dotPeek، وده بيعرض كود النظام للاختراق.
AOT (Ahead of Time):
في AOT، الكود بيتحول لـ Native Machine Code أثناء عملية البناء (Build)، وده بيكون مخصص للمنصة وصعب جدًا يتم عكسه.
✅ المميزات:
أمان الكود: المخرجات بتكون Native Binary، وده بيصعب عملية فك الكود (Decompiling).
سرعة في تشغيل التطبيق (Startup Time).
❌ العيوب:
دعم محدود للميزات الديناميكية زي الـ Reflection.
عملية الـ Build بتاخد وقت أطول.
ليه تستخدم AOT للحماية؟
لو حماية كود النظام أو الملكية الفكرية أولوية بالنسبة لك، AOT بيوفر طبقة إضافية من الأمان ضد الهندسة العكسية. صحيح مش حماية 100%، لكنه أكثر أمانًا بكتير من كود IL الناتج عن JIT.
أمتى تستخدم كل واحد؟
AOT:
لما الأمان وسرعة التشغيل تكون عوامل رئيسية.
النظام يكون داخلي وغير معرض للعمل على أنواع مختلفة من أنظمة التشغيل.
JIT:
لما تحتاج مرونة وتحسين أثناء التشغيل.
مناسب للتطبيقات Server-Side الكبيرة.
قرارك سيعتمد على احتياجات المشروع. دمتم سالمين.
Forwarded from الرسمية CS4 Class-22 (أحمد جلال | 𐩱𐩢𐩣𐩵 𐩴𐩡𐩱𐩡)
#صنعــــــــــاء
#مطلوب مبرمج PHP Laravel
وظيفة شاغرة بداوم كامل للمبرمجين المتفرغين ذوي الخبرة العالية في لغة PHP Laravel، يشترط إثبات الخبرة من خلال مشاريع سابقة.
يُرجى إرسال السيرة الذاتية إلى hr@athkaholidays.com
سيتم تحديد الراتب بعد المقابلة الشخصية بناءً على المؤهلات والخبرات.
للتواصل حول التقديم والتفاصيل واتس أو هاتف +967779556911
تابع القناة ليصلك كل جديد 😌🫱🏻🫲🏻
https://whatsapp.com/channel/0029VaAS0Na1noz5lIl30M0w
#منح_وفرص
#مطلوب مبرمج PHP Laravel
وظيفة شاغرة بداوم كامل للمبرمجين المتفرغين ذوي الخبرة العالية في لغة PHP Laravel، يشترط إثبات الخبرة من خلال مشاريع سابقة.
يُرجى إرسال السيرة الذاتية إلى hr@athkaholidays.com
سيتم تحديد الراتب بعد المقابلة الشخصية بناءً على المؤهلات والخبرات.
للتواصل حول التقديم والتفاصيل واتس أو هاتف +967779556911
تابع القناة ليصلك كل جديد 😌🫱🏻🫲🏻
https://whatsapp.com/channel/0029VaAS0Na1noz5lIl30M0w
#منح_وفرص
WhatsApp.com
منح وفرص
Channel • 16K followers • أهلاً وسهلاً بالأعزاء جميعاً 💙🔥
نرحب بكم في القناة التابعة لمنصة منح وفرص، والتي سيُنشر من خلالها:
- المنح الداخلية والخارجية
- الوظائف المتاحة
- الفعاليات والمؤتمرات
- برامج وورش التدريب
- فرص التطوع
- فرص التعليم الذاتي
- المسابقات…
نرحب بكم في القناة التابعة لمنصة منح وفرص، والتي سيُنشر من خلالها:
- المنح الداخلية والخارجية
- الوظائف المتاحة
- الفعاليات والمؤتمرات
- برامج وورش التدريب
- فرص التطوع
- فرص التعليم الذاتي
- المسابقات…
رحلة
"البرمجة الكائنية التوجه" (OOP): كيف يمكن أن تجعل حياتك أسهل؟
تخيل لو كنت تستطيع بناء شيء معقد مثل سيارة، ولكنك لا تحتاج إلى أن تكون خبيرًا في المحرك أو التفاصيل الصغيرة. كل ما عليك هو أن تعرف كيف تقود السيارة، وستقوم بقيادتها بكل سلاسة. هذا هو ما تعنيه "البرمجة الكائنية التوجه"! نستخدم فيها أربعة مفاهيم رئيسية تجعل عملنا أسهل وأكثر مرونة:
1. التجريد (Abstraction):
فكر في التجريد كأنك تستخدم جهاز التحكم عن بعد للتلفاز. لا تحتاج لمعرفة كل التفاصيل الداخلية في الجهاز، فقط تضغط على الأزرار لتغيير القنوات أو الصوت. بنفس الطريقة، في البرمجة، نحن نركز فقط على ما نحتاجه ولا نهتم بكيفية عمل الأشياء الداخلية.
2. التوريث (Inheritance):
التوريث مثلما ترث من والديك بعض الصفات (كالطول أو لون العينين). في البرمجة، إذا كنت قد كتبت كودًا لشيء ما (مثلاً سيارة)، يمكنك أن "ترث" هذا الكود وتضيف عليه خصائص جديدة (مثل إضافة ميزات متقدمة في سيارة جديدة).
3. التعددية الشكلية (Polymorphism):
التعددية الشكلية هي مثل أن تكون لديك مفتاح واحد يُستخدم لفتح أبواب مختلفة. في البرمجة، يمكن أن يستخدم نفس الكود وظائف متعددة بطرق مختلفة حسب الحاجة. على سبيل المثال، قد تكون لديك وظيفة واحدة لفتح باب، ولكن يمكن أن تفتح أبوابًا مختلفة حسب نوع السيارة أو المنزل.
4. التركيب (Composition):
التركيب يشبه بناء جهاز معقد مثل الهاتف الذكي. في هذا الهاتف، لديك كاميرا، شاشة، معالج، وبطارية كلها تعمل معًا لتكوين جهاز متكامل. في البرمجة، يمكننا دمج كائنات مختلفة (مثل محرك السيارة، العجلات، والمقاعد) لتكوين شيء أكبر يعمل كوحدة واحدة.
لماذا هذه المفاهيم مهمة؟
تخيل أنك تبني مشروعًا كبيرًا في البرمجة، مثل موقع على الإنترنت أو لعبة. ستحتاج إلى هيكل يمكنه التكيف مع التغييرات بسهولة. هنا تأتي البرمجة الكائنية التوجه، التي تجعل من السهل إضافة أو تعديل وظائف جديدة دون أن تكسر النظام ككل.
"إذا كنت تُريد أن تبني شيء مستدام، فابنِ على أساس قوي، والبرمجة الكائنية التوجه هي الأساس."
وشكرًا
"البرمجة الكائنية التوجه" (OOP): كيف يمكن أن تجعل حياتك أسهل؟
تخيل لو كنت تستطيع بناء شيء معقد مثل سيارة، ولكنك لا تحتاج إلى أن تكون خبيرًا في المحرك أو التفاصيل الصغيرة. كل ما عليك هو أن تعرف كيف تقود السيارة، وستقوم بقيادتها بكل سلاسة. هذا هو ما تعنيه "البرمجة الكائنية التوجه"! نستخدم فيها أربعة مفاهيم رئيسية تجعل عملنا أسهل وأكثر مرونة:
1. التجريد (Abstraction):
فكر في التجريد كأنك تستخدم جهاز التحكم عن بعد للتلفاز. لا تحتاج لمعرفة كل التفاصيل الداخلية في الجهاز، فقط تضغط على الأزرار لتغيير القنوات أو الصوت. بنفس الطريقة، في البرمجة، نحن نركز فقط على ما نحتاجه ولا نهتم بكيفية عمل الأشياء الداخلية.
2. التوريث (Inheritance):
التوريث مثلما ترث من والديك بعض الصفات (كالطول أو لون العينين). في البرمجة، إذا كنت قد كتبت كودًا لشيء ما (مثلاً سيارة)، يمكنك أن "ترث" هذا الكود وتضيف عليه خصائص جديدة (مثل إضافة ميزات متقدمة في سيارة جديدة).
3. التعددية الشكلية (Polymorphism):
التعددية الشكلية هي مثل أن تكون لديك مفتاح واحد يُستخدم لفتح أبواب مختلفة. في البرمجة، يمكن أن يستخدم نفس الكود وظائف متعددة بطرق مختلفة حسب الحاجة. على سبيل المثال، قد تكون لديك وظيفة واحدة لفتح باب، ولكن يمكن أن تفتح أبوابًا مختلفة حسب نوع السيارة أو المنزل.
4. التركيب (Composition):
التركيب يشبه بناء جهاز معقد مثل الهاتف الذكي. في هذا الهاتف، لديك كاميرا، شاشة، معالج، وبطارية كلها تعمل معًا لتكوين جهاز متكامل. في البرمجة، يمكننا دمج كائنات مختلفة (مثل محرك السيارة، العجلات، والمقاعد) لتكوين شيء أكبر يعمل كوحدة واحدة.
لماذا هذه المفاهيم مهمة؟
تخيل أنك تبني مشروعًا كبيرًا في البرمجة، مثل موقع على الإنترنت أو لعبة. ستحتاج إلى هيكل يمكنه التكيف مع التغييرات بسهولة. هنا تأتي البرمجة الكائنية التوجه، التي تجعل من السهل إضافة أو تعديل وظائف جديدة دون أن تكسر النظام ككل.
"إذا كنت تُريد أن تبني شيء مستدام، فابنِ على أساس قوي، والبرمجة الكائنية التوجه هي الأساس."
وشكرًا
❤3
🤔
1. برمجة الأكوان الافتراضية
كيف يمكننا محاكاة كون كامل باستخدام البرمجة؟
هل يمكن تصميم قوانين فيزيائية جديدة مختلفة عن تلك التي تحكم عالمنا؟
2. مستقبل الذكاء الاصطناعي في تفسير الأحلام
ماذا لو تمكّن الذكاء الاصطناعي من فهم أحلامك وتحويلها إلى أفلام أو روايات؟
كيف يمكن للبرمجة العصبية المساعدة في دراسة اللاوعي البشري؟
3. بناء عقول رقمية: ما بعد الدماغ البشري
ماذا لو استطعنا برمجة عقول اصطناعية يمكنها أن تشعر بالإبداع؟
كيف سيكون شكل الفن أو الموسيقى المنتجة بواسطة "عقل رقمي"؟
4. الأكواد التي تكتب نفسها (Self-Writing Code)
هل يمكن أن تصل البرمجة إلى مستوى يتم فيه إنشاء الأكواد تلقائيًا بواسطة الذكاء الاصطناعي؟
ما هي الأخلاقيات وراء الكود الذي يطوّر نفسه ويتعلّم باستمرار؟
5. البرمجة الزمنية: التلاعب بالوقت من خلال الأكواد
كيف يمكن للبرمجة محاكاة السفر عبر الزمن أو استرجاع اللحظات الماضية؟
بناء محاكيات تتبع تطور الأحداث التاريخية بتعديلات طفيفة في نقاط القرار الرئيسية.
6. الخيال الحاسوبي: عالم القصص التفاعلية
برمجة روايات تفاعلية يمكن للقارئ أن يغيّر مسارها.
هل يمكن للحواسيب كتابة قصص تفوق خيال البشر؟
7. هندسة العواطف الرقمية
تصميم واجهات مستخدم يمكنها أن تستشعر مزاجك وتغير التجربة بناءً على حالتك النفسية.
تطوير ألعاب أو تطبيقات تتفاعل بناءً على شعورك الحالي.
8. العوالم متعددة الأبعاد (Multi-Dimensional Coding)
برمجة عوالم تتجاوز البعد الثالث، كيف يمكن للتكنولوجيا أن تعيد تعريف الأبعاد؟
إنشاء بيئات افتراضية حيث يمكن للمستخدمين التنقل بين أبعاد مختلفة.
9. بناء ذكاء اصطناعي يتمتع بفضول لا محدود
تصميم أنظمة ذكاء اصطناعي تسعى لفهم كل شيء، من قوانين الكون إلى تفاصيل الحياة اليومية.
كيف سيكون شكل الحوار مع "آلة فضولية"؟
10. البرمجة الحية: الأكواد التي تتنفس
تصميم برامج تُظهر "حياة رقمية" تنمو وتتغير مع مرور الوقت.
ماذا لو كانت الأنظمة البرمجية تتكيف مع المستخدم بدلاً من العكس؟
11. إعادة تعريف الهوية الإنسانية من خلال التكنولوجيا
كيف يمكن للبرمجة أن تدمج بين العقل البشري والعقل الاصطناعي؟
استكشاف حدود "البشرية" في عالم تقني بحت.
12. تصميم المستقبل باستخدام الأكواد
برمجة نماذج تُحاكي شكل الحضارة بعد 500 عام بناءً على الخيارات التي نتخذها اليوم.
كيف يمكن للذكاء الاصطناعي أن يساعدنا في اتخاذ قرارات تُشكّل المستقبل؟
13. لغة برمجة مستوحاة من الطبيعة
تصميم لغات برمجة تُحاكي قوانين الطبيعة (مثل دورة الحياة أو النمو العضوي).
كيف يمكن لهذه اللغات أن تُغيّر طريقة التفكير البرمجي؟
14. التخاطر الرقمي: قراءة ونقل الأفكار عبر الأكواد
ماذا لو استطعنا استخدام التكنولوجيا لنقل الأفكار بين العقول مباشرة؟
هل يمكن أن تكون البرمجة هي لغة التخاطر المستقبلية؟
15. "الكود الحي": أنظمة برمجية لا تموت أبدًا
بناء أنظمة تبقى حية للأبد، تتطور مع الزمن دون الحاجة إلى تحديثات يدوية.
1. برمجة الأكوان الافتراضية
كيف يمكننا محاكاة كون كامل باستخدام البرمجة؟
هل يمكن تصميم قوانين فيزيائية جديدة مختلفة عن تلك التي تحكم عالمنا؟
2. مستقبل الذكاء الاصطناعي في تفسير الأحلام
ماذا لو تمكّن الذكاء الاصطناعي من فهم أحلامك وتحويلها إلى أفلام أو روايات؟
كيف يمكن للبرمجة العصبية المساعدة في دراسة اللاوعي البشري؟
3. بناء عقول رقمية: ما بعد الدماغ البشري
ماذا لو استطعنا برمجة عقول اصطناعية يمكنها أن تشعر بالإبداع؟
كيف سيكون شكل الفن أو الموسيقى المنتجة بواسطة "عقل رقمي"؟
4. الأكواد التي تكتب نفسها (Self-Writing Code)
هل يمكن أن تصل البرمجة إلى مستوى يتم فيه إنشاء الأكواد تلقائيًا بواسطة الذكاء الاصطناعي؟
ما هي الأخلاقيات وراء الكود الذي يطوّر نفسه ويتعلّم باستمرار؟
5. البرمجة الزمنية: التلاعب بالوقت من خلال الأكواد
كيف يمكن للبرمجة محاكاة السفر عبر الزمن أو استرجاع اللحظات الماضية؟
بناء محاكيات تتبع تطور الأحداث التاريخية بتعديلات طفيفة في نقاط القرار الرئيسية.
6. الخيال الحاسوبي: عالم القصص التفاعلية
برمجة روايات تفاعلية يمكن للقارئ أن يغيّر مسارها.
هل يمكن للحواسيب كتابة قصص تفوق خيال البشر؟
7. هندسة العواطف الرقمية
تصميم واجهات مستخدم يمكنها أن تستشعر مزاجك وتغير التجربة بناءً على حالتك النفسية.
تطوير ألعاب أو تطبيقات تتفاعل بناءً على شعورك الحالي.
8. العوالم متعددة الأبعاد (Multi-Dimensional Coding)
برمجة عوالم تتجاوز البعد الثالث، كيف يمكن للتكنولوجيا أن تعيد تعريف الأبعاد؟
إنشاء بيئات افتراضية حيث يمكن للمستخدمين التنقل بين أبعاد مختلفة.
9. بناء ذكاء اصطناعي يتمتع بفضول لا محدود
تصميم أنظمة ذكاء اصطناعي تسعى لفهم كل شيء، من قوانين الكون إلى تفاصيل الحياة اليومية.
كيف سيكون شكل الحوار مع "آلة فضولية"؟
10. البرمجة الحية: الأكواد التي تتنفس
تصميم برامج تُظهر "حياة رقمية" تنمو وتتغير مع مرور الوقت.
ماذا لو كانت الأنظمة البرمجية تتكيف مع المستخدم بدلاً من العكس؟
11. إعادة تعريف الهوية الإنسانية من خلال التكنولوجيا
كيف يمكن للبرمجة أن تدمج بين العقل البشري والعقل الاصطناعي؟
استكشاف حدود "البشرية" في عالم تقني بحت.
12. تصميم المستقبل باستخدام الأكواد
برمجة نماذج تُحاكي شكل الحضارة بعد 500 عام بناءً على الخيارات التي نتخذها اليوم.
كيف يمكن للذكاء الاصطناعي أن يساعدنا في اتخاذ قرارات تُشكّل المستقبل؟
13. لغة برمجة مستوحاة من الطبيعة
تصميم لغات برمجة تُحاكي قوانين الطبيعة (مثل دورة الحياة أو النمو العضوي).
كيف يمكن لهذه اللغات أن تُغيّر طريقة التفكير البرمجي؟
14. التخاطر الرقمي: قراءة ونقل الأفكار عبر الأكواد
ماذا لو استطعنا استخدام التكنولوجيا لنقل الأفكار بين العقول مباشرة؟
هل يمكن أن تكون البرمجة هي لغة التخاطر المستقبلية؟
15. "الكود الحي": أنظمة برمجية لا تموت أبدًا
بناء أنظمة تبقى حية للأبد، تتطور مع الزمن دون الحاجة إلى تحديثات يدوية.
الفرق بين هياكل البيانات و OOP:
هياكل البيانات:
طريقة لتنظيم البيانات (مثل الأدراج لتخزين الأشياء).
مثال: قائمة بأسماء طلاب الصف.
OOP:
أسلوب لتصميم البرامج باستخدام كائنات تجمع البيانات والسلوك معًا.
مثال: كائن "طالب" يحتوي على الاسم (بيانات) وطريقة "يجيب على سؤال" (سلوك).
العلاقة:
OOP تستخدم هياكل البيانات لتنظيم البيانات داخل الكائنات.
هياكل البيانات:
طريقة لتنظيم البيانات (مثل الأدراج لتخزين الأشياء).
مثال: قائمة بأسماء طلاب الصف.
OOP:
أسلوب لتصميم البرامج باستخدام كائنات تجمع البيانات والسلوك معًا.
مثال: كائن "طالب" يحتوي على الاسم (بيانات) وطريقة "يجيب على سؤال" (سلوك).
العلاقة:
OOP تستخدم هياكل البيانات لتنظيم البيانات داخل الكائنات.
شرح Big O من واقع الحياة
تخيل أنك في سوق كبير وتحتاج إلى إنجاز مهمات، وسرعة إنجازك تعتمد على طريقة العمل. كل طريقة تمثل نوعًا من التعقيد الزمني في Big O.
---
1. O(1) - وقت ثابت (Instant Access)
المثال الواقعي:
لديك قائمة تسوق صغيرة على ورقة، وتعرف مكان "الطماطم" مباشرة. لا يهم حجم السوق، تذهب مباشرة إلى الرف المطلوب وتأخذ الطماطم.
الفكرة:
الزمن ثابت ولا يتأثر بحجم المشكلة.
مثل: قراءة أول عنصر في قائمة.
---
2. O(n) - خطي (Linear Time)
المثال الواقعي:
تبحث عن "أفضل تفاح" في السوق، وتفحص كل تفاحة واحدة تلو الأخرى حتى تنتهي من كل التفاح الموجود.
الفكرة:
كلما زاد عدد العناصر (تفاح أكثر)، زاد الوقت اللازم للبحث.
مثل: المرور على قائمة أسماء بالكامل.
---
3. O(n²) - تربيعي (Quadratic Time)
المثال الواقعي:
تقوم بمقارنة كل نوع من الفاكهة في السوق مع كل نوع آخر لتقرر أيهما الأفضل.
إذا كان لديك 10 أنواع فواكه، ستقوم بـ100 مقارنة! (10 × 10).
الفكرة:
كل عنصر يتفاعل مع كل عنصر آخر.
مثل: ترتيب قائمة باستخدام خوارزمية فاشلة.
---
4. O(log n) - لوغاريتمي (Logarithmic Time)
المثال الواقعي:
تبحث عن كتاب في مكتبة ضخمة، وتستخدم طريقة "ابحث في النصف":
تبدأ بالمنتصف: إذا لم يكن الكتاب هناك، تذهب إلى النصف الآخر، وهكذا.
تقلل خيارات البحث إلى النصف في كل خطوة.
الفكرة:
الوقت ينخفض بشكل كبير كلما قسّمت المشكلة.
مثل: البحث الثنائي.
---
5. O(2^n) - أُسي (Exponential Time)
المثال الواقعي:
تجرب كل الطرق الممكنة للوصول إلى منزل صديقك في مدينة غريبة.
إذا كانت هناك طريقان لكل منعطف، ستزداد الخيارات بشكل جنوني مع زيادة عدد المنعطفات.
الفكرة:
كل إضافة صغيرة للمشكلة تضاعف الزمن المطلوب بشكل هائل.
مثل: حل ألغاز معقدة جدًا.
---
الفكرة العامة:
كل نوع من Big O يصف كم يزداد الوقت مع زيادة حجم المشكلة.
O(1): سريع جدًا، دائمًا نفس الوقت.
O(n): يزداد مع زيادة عدد العناصر.
O(n²): يتضاعف بشكل كبير مع كل عنصر جديد.
O(log n): سريع جدًا، يقل الوقت مع تقسيم المشكلة.
O(2^n): بطيء جدًا، يزيد بشكل جنوني.
التشبيه: كل Big O هو "طريقة تفكير" لتنظيم وقتك حسب المهمة!
تخيل أنك في سوق كبير وتحتاج إلى إنجاز مهمات، وسرعة إنجازك تعتمد على طريقة العمل. كل طريقة تمثل نوعًا من التعقيد الزمني في Big O.
---
1. O(1) - وقت ثابت (Instant Access)
المثال الواقعي:
لديك قائمة تسوق صغيرة على ورقة، وتعرف مكان "الطماطم" مباشرة. لا يهم حجم السوق، تذهب مباشرة إلى الرف المطلوب وتأخذ الطماطم.
الفكرة:
الزمن ثابت ولا يتأثر بحجم المشكلة.
مثل: قراءة أول عنصر في قائمة.
---
2. O(n) - خطي (Linear Time)
المثال الواقعي:
تبحث عن "أفضل تفاح" في السوق، وتفحص كل تفاحة واحدة تلو الأخرى حتى تنتهي من كل التفاح الموجود.
الفكرة:
كلما زاد عدد العناصر (تفاح أكثر)، زاد الوقت اللازم للبحث.
مثل: المرور على قائمة أسماء بالكامل.
---
3. O(n²) - تربيعي (Quadratic Time)
المثال الواقعي:
تقوم بمقارنة كل نوع من الفاكهة في السوق مع كل نوع آخر لتقرر أيهما الأفضل.
إذا كان لديك 10 أنواع فواكه، ستقوم بـ100 مقارنة! (10 × 10).
الفكرة:
كل عنصر يتفاعل مع كل عنصر آخر.
مثل: ترتيب قائمة باستخدام خوارزمية فاشلة.
---
4. O(log n) - لوغاريتمي (Logarithmic Time)
المثال الواقعي:
تبحث عن كتاب في مكتبة ضخمة، وتستخدم طريقة "ابحث في النصف":
تبدأ بالمنتصف: إذا لم يكن الكتاب هناك، تذهب إلى النصف الآخر، وهكذا.
تقلل خيارات البحث إلى النصف في كل خطوة.
الفكرة:
الوقت ينخفض بشكل كبير كلما قسّمت المشكلة.
مثل: البحث الثنائي.
---
5. O(2^n) - أُسي (Exponential Time)
المثال الواقعي:
تجرب كل الطرق الممكنة للوصول إلى منزل صديقك في مدينة غريبة.
إذا كانت هناك طريقان لكل منعطف، ستزداد الخيارات بشكل جنوني مع زيادة عدد المنعطفات.
الفكرة:
كل إضافة صغيرة للمشكلة تضاعف الزمن المطلوب بشكل هائل.
مثل: حل ألغاز معقدة جدًا.
---
الفكرة العامة:
كل نوع من Big O يصف كم يزداد الوقت مع زيادة حجم المشكلة.
O(1): سريع جدًا، دائمًا نفس الوقت.
O(n): يزداد مع زيادة عدد العناصر.
O(n²): يتضاعف بشكل كبير مع كل عنصر جديد.
O(log n): سريع جدًا، يقل الوقت مع تقسيم المشكلة.
O(2^n): بطيء جدًا، يزيد بشكل جنوني.
التشبيه: كل Big O هو "طريقة تفكير" لتنظيم وقتك حسب المهمة!
👍2
الفرق بين Normalization و Denormalization:
Normalization:
هي عملية تبسيط الجدول إلى كيانات أبسط مع إزالة التكرار والاعتمادات الجزئية.
الأنواع الشائعة:
1NF: إزالة التكرار في الحقول والتأكد أن كل عمود يحتوي على قيمة واحدة.
2NF: إزالة الاعتماد الجزئي على المفتاح الأساسي.
3NF: فصل الكيانات إلى كيانات أصغر مرتبطة بالمفتاح الأساسي إذا كان هناك ارتباط بجدول آخر.
Denormalization:
هي عملية تجميع الكيانات في جدول واحد، مما قد يؤدي إلى تكرار البيانات في الحقول.
بالنسبة للتقارير:
Denormalization أفضل لأنها أسرع، خاصة مع البيانات الكبيرة أثناء البحث والاستعلام.
Normalization أفضل من حيث تقسيم التقارير لكل جدول بشكل منفصل.
Normalization:
هي عملية تبسيط الجدول إلى كيانات أبسط مع إزالة التكرار والاعتمادات الجزئية.
الأنواع الشائعة:
1NF: إزالة التكرار في الحقول والتأكد أن كل عمود يحتوي على قيمة واحدة.
2NF: إزالة الاعتماد الجزئي على المفتاح الأساسي.
3NF: فصل الكيانات إلى كيانات أصغر مرتبطة بالمفتاح الأساسي إذا كان هناك ارتباط بجدول آخر.
Denormalization:
هي عملية تجميع الكيانات في جدول واحد، مما قد يؤدي إلى تكرار البيانات في الحقول.
بالنسبة للتقارير:
Denormalization أفضل لأنها أسرع، خاصة مع البيانات الكبيرة أثناء البحث والاستعلام.
Normalization أفضل من حيث تقسيم التقارير لكل جدول بشكل منفصل.
الناس كلها بتفكر تعمل مشاريع بالAI وأنا بفكر أفتح مشروع شاي كرك في صنعاء .
شوية مكن ومكونات من الهند ولا الصين وأبيع الكوباية ب2000-3000 الف ريال وفي سوق فاضي مفيش فيه إلا كام منافس ايه رائيك 🤔😅
شوية مكن ومكونات من الهند ولا الصين وأبيع الكوباية ب2000-3000 الف ريال وفي سوق فاضي مفيش فيه إلا كام منافس ايه رائيك 🤔😅
🔥4
Forwarded from الرسمية CS4 Class-22 (أحمد جلال | 𐩱𐩢𐩣𐩵 𐩴𐩡𐩱𐩡)
السلام عليكم ورحمة الله.
🛑يرجى التعميم🛑
في شركة تحتاج موظف React متفرغ لايوجد معه أرتباطات بأي جهة أطلاقا.
يكون فاهم React بشكل أحترافي جدا جدا.
ويفضل يكون ذو خبره سابقة وأشتغل على أنظمة محاسبية متكاملة.
العمل بيكون على نظام محاسبي كبير جدا ويحتاج شخص متقن ومحترف في React
للتقديم يرجى ارسال السيرة الذاتية واتساب على الرقم التالي.
+967772302176
🛑يرجى التعميم🛑
في شركة تحتاج موظف React متفرغ لايوجد معه أرتباطات بأي جهة أطلاقا.
يكون فاهم React بشكل أحترافي جدا جدا.
ويفضل يكون ذو خبره سابقة وأشتغل على أنظمة محاسبية متكاملة.
العمل بيكون على نظام محاسبي كبير جدا ويحتاج شخص متقن ومحترف في React
للتقديم يرجى ارسال السيرة الذاتية واتساب على الرقم التالي.
+967772302176