VOL75: Halo Gameplay Scales Beyond Billion of Games Using Saga Pattern
أهلًا وسهلا بكم في العدد الخامس والسبعين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الخامس والسبعين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
Halo Gameplay Scales Beyond Billion of Games Using Saga Pattern
Top 16 Kubernetes Essential Components
Vodafone Big Data Services Behind The Scene
الإصدار الأول من مدونات فطين في تصميم النظم
Halo Gameplay Scales Beyond Billion of Games Using Saga Pattern
سلسلة Halo من أكتر ألعاب التصويب شهرة على Xbox، وخصوصًا مع Halo 4 حصل انفجار ضخم في أعداد اللاعبين والجيمز: ملايين المستخدمين، ومليارات الجيمز المتسجّلة. ورا التجربة دي فيه منظومة Distributed Systems كبيرة بتلمّ Statistics لكل لاعب بعد كل ماتش—عدد القتلات، المساعدات، الدقة، إلخ—وبتعرُضها على موقعهم وخدمات تانية.
المعضلة بدأت لما البنية القديمة كانت مبنية على SQL Database واحدة كـ Source of Truth، وده ما بقاش بيـ Scale مع الأرقام المهولة دي.
الأرقام بتاعة Halo 4 كانت مرعبة وده لإن تقريبًا كان فيه 1.5 billion games played و11.6 million مستخدم. فكان واضح إن Single Giant SQL Database مش هتستحمل.
فقرروا يعيدوا كتابة الـ Services وينقلوها لـ Azure Cloud، واستعملوا Azure Table Storage كأكبر شكل من الـ NoSQL — Key-Value Store. وده خلق تحدّي كبير: زمان هم كانوا عايشين على الـ Transactions في Database واحدة والي بالتأكيد بتضمن الـ Consistency، دلوقتي البيانات متقسّمة على Partitions كتير.
Halo Journey to Scale
الفريق بدأ يفكر بشكل كبير ازاي يقدروا يحلوا المشكلة دي ، لحد ما وقع قدامهم الورقة البحثية من 1987 واللي كانت بتتكلم عن الـ Saga Pattern ، فطبقوا الكلام ده عشان يقدروا يعملوا Processing للاحصائيات بطريقة شبه Transactional ، وبنقول هنا “شبه Transactional” عشان بالتأكيد كان فيه تنازلات عن شوية ضمانات قرروا يتنازلوا عنها زي مثلا ان مفيش Serializability ولكن في النهاية ده كان في سبيل تحقيق الـ Consistency من بداية لنهاية الـ Transaction ويعرفوا يتصرفوا في الـ Failure Scenarios.
الطبيعي إن أي System بيكون في بدايته بسيط جدًا فبيكون عبارة عن App أو Website بيكلم Stateless Service واللي بدورها بتكلم Database ضخمة وبالتالي بناخد الضمانات الجميلة اللي كلنا عارفينها من الـ ACID Properties زي الـ Transactions والـ Serializability وغيرهم.
وكتذكرة الـ Serializability هي بكل بساطة عبارة عن ضمان بيضمن إن كل العمليات الـ Concurrent تبان إنها هتحصل بشكل Sequential بدون أي مشاكل أو بدون مالعمليات تدخل في شغل بعضها.
والـ ACID عملنا عنها ورقة قبل كده فتقدروا تشوفوها من الرابط ده:
In Real World
ده كان الحال زمان ، ولكن دلوقتي احنا عايشين وسط الـ Microservices والـ Distributed Systems فموضوع ان يكون عندنا Database واحدة هي الـ Single Source of Truth مبقاش واقعي وكمان لما بنيجي نبني نطبيقات حاليًا فالتطبيقات دي بشكل ما أو بآخر هتكون يا بتكلم الـ Internal APIs بتاعتنا يا هتكون بتكلم APIs مختلفة وبتاعة حد تاني وكل APIs من دي هتكون Behind The Scene عندها الـ Database اللي بتتعامل معاها.
فمفيش حاليًا Database واحدة عملاقة فيها كل البيانات اللي محتاجينها.
Two-Phase Commit
وعشان نحل مشكلة الـ Distributed Transaction في الـ Distributed Systems ظهر الأول مفهوم الـ Two Phase Commit وده عبارة عن Atomic Commitment Protocol ونوع فريد من الـ Consensus Protocol واللي فيه بيكون عندنا 2 Phases أو مرحلتين ، وهم الـ Prepare / Commit.
ووقتا الـ Coordinator بيجمع الأصوات دي كلها ، ونبدأ مرحلة الـ Commit Phase واللي وقتها لو كل الـ Services جاوت بنعم انها جاهزة تنفذ الـ Transaction ، فبيبعت الـ Transaction لكل Service لان كل Service خلاص أكدت أو صوتت بنعم أو Commit إنها تنفذه وجاهزة لتنفيذه.
وفي النهاية بعد ما كل Service تشتغل على الـ Transaction بترد بالآخر بـ Done بحيث الـ Coordinator يكون عارف النتيجة النهائية من كل Service ويقدر بناء عليها يحدد اذا كان خلاص تمام ولا فيه مشكلة وهنضطر نـ Abort.
شركات كتير بتستعمل الـ 2PC لحل مشكلة الـ Distributed Transactions ولكن مشكلة الحل ده إنه بيكون ماشي كويس في البداية لحد ما نوصل لنقطة إنه مش Scalable.
لو فيه Failures ممكن نوصل لـ O(N^2) رسالة رايحة جاية جوا الـ System
الـ Coordinator هو Single Point of Failure فلو فيه مشكللة حصلت ووقع مننا في نص الـ Transaction ، الـ Transaction كله هيبقى Aborted حتى لو الـ Services التانية شغالة كويس.
ولو عندنا Resources او Services كتير داخلة في الـ Transaction فاحنا عرضة طبعًا للـ Latency وبالتالي هنكون مرتبطين ومضطرين نصبر ونكون Bounded بأبطأ Resource أو Service في النظام بتاعنا.
الـ Throughput كمان مش أفضل حاجة وده لإننا بنكون ماسكين Locks على الـ Resources دي واحنا شغالين في الـ Transaction ومش عاوزين حاجة تعدل أو تغير فيهم وسط الـ Transaction اللي شغال.
بالاضافة كمان إن معظم الـ Cloud Providers في الشركات الكبيرة زي Google , Azure مش بيستعملوه بسبب المشاكل الي ذكرناها وانه مش بيـ Scale بشكل كويس.
Google Spinner
بالنسبة لشركة Google فهي عندها Spinner ودي الـ Distributed Database بتاعتهم وكمان كانوا عملوا Paper ليها وبتحقق الـ Distributed Transactions من خلال الـ TrueTime API باستعمال الـ GPS و الـ Atomic Clocks في الـ Data Centers بتاعتهم.
بالإضافة كمان إن الـ Data Centers بتاعتهم مربوطة ببعضها بـ Fibers خاصة بيها فأغلب مشاكل الـ Network اللي الشركات بتمر بيها هم في غنى عنها بشكل كبيرا.
واللي بيعمله الـ TrueTimeAPI هو إنه بياخد كل الـ inputs من الـ system واللي بيتضمن الـ GPS والـ Atomic Clocks وبعدين يحسب الـ Time Bound للوقت اللي حصل فيه الـ Event وبالتالي يقدروا يستعملوه في إنهم يحددوا الترتيب الزمني السليم للـ Events اللي حصلت بترتيبها.
وجب القول برضو إن ده بيكون عرضة لـ Downtime قدره بيكون حوالي 7 مللي ثانية ، فالـ Synchronization مش 100% ولكن من خلال الـ Time Bound Window الصغيرة جدًا دي بيشتغل بشكل كويس.
طب ايه اللي مخلهمش ياخدوا قرار إنهم يستعلموا Google Spinner ؟ ده لإنه في الواقع كان وقته غالي جدًا بالإضافة كمان لإن الـ Synchronization لسه مشكلة ملهاش حل.
Complexity of Distributed Transactions
اللي محتاجين نفهمه في الرحلة دي لحد دلوقتي واللي عاوزينه يوصل للكل هو إن الـ Distributed Transactions مكلفة جدًا وصعبة جدًا في التعامل معاها ، خصوصا كمان لو محتاجين الـ System يكون فيه الـ Serializability والـ ACID متحققين زي قواعد البيانات العادية.
Saga Pattern
ومن هنا بدأت الـ Sagas ، الـ Saga هو عبارة عن Long Lived Transaction يعني Transaction عمره طويل شويتين واللي بيكون متمثل كـ Sequence من الـ Sub Transactions المختلفة واللي ممكن يحصلهم تداخل مع بعضهم البعض.
فزي ماحنا شايفين قبل ما يكون عندنا Saga كنا بنبعت Single Transaction اسمه Book Trip ولكن دلوقتي ده هيتقسم لـ Sub Transactions وهم الـ Book Car, Book Hotel وكمان Book Flight فبقى عندنا Sub Transaction كل واحد فيهم ليه الـ Compensating Transaction الخاص بيه.
حاجة تانية مهمة نذكرها هنا إن ليه بنضطر نلجأ للـ Compensating Transactions ؟ لإن في بعض الحالات هنلاقي إن ما ينفعش نعمل Undo ، زي مثلا فيه System بعت Email خلاص مش هنعرف نلغي العملية دي ، فبالتالي بيكون فيه مثلا Compensating Transactions إننا نعمل Follow-up Email يصلح اللي حصل كـ Corrective Action.
Saga Execution Coordinator
طب ازاي الكلام ده بيشتغل فعليًا ؟ لو احنا مكملين في مثال الـ Single Database عشان الموضوع يكون أسهل للشرح ، فاحنا بيكون عندنا Process قايمة بجانب الـ Database اسمها SEC وهي اختصار لـ Saga Execution Coordinator.
Top 16 Kubernetes Essential Components
النهارده هنتكلم عن أهم مكونات Kubernetes وهو نظام مفتوح المصدر لإدارة ونشر وتشغيل التطبيقات داخل حاويات (Containers) بشكل آلي وفعّال.
يعتبر K8s أشهر ال Orchestrators حاليًا وبتظهر أهميته في الشركات الكبيرة وبيئات ال Microservices المعقدة لأنه يقدر يدير ويسهل عملية نشر التطبيقات بطريقة منظمة وقابلة للتوسع. هنتكلم بشكل مختصر عن أهم المكونات وإزاي بتتواصل مع بعضها البعض.
أهم مكونات Kubernetes الأساسية
1- Container: هي حاوية تحمل بداخلها التطبيق مع بيئة كاملة تشمل كل ما يحتاجه من اعتماديات ليعمل.
2- Pod: أصغر وحدة Deployable في K8s ، تحتوي على حاوية واحدة أو أكثر تُدار معًا وتشارك نفس الـ IP والـ Volume.
3- Node: خادم (فعلي أو افتراضي) يعمل عليه K8s ويشغّل الـ Pods. وتسمي ال Node ب Worker Node عندما تقوم بتشغيل ال(Pods) التي تم جدولة تشغيلها من قبل الـ Master.
4- Cluster: يُسمي النظام الذي يديره K8S بال Cluster ويتكون من مجموعة من الـ Nodes تُدار كوحدة واحدة لتشغيل التطبيقات.
5- Control Plane: أو تسمى بال Master Node وهي المسؤولة عن إدارة الـ Cluster بأكمله عن طريق عدة مكونات.
6- Kubelet: هو Agent يعمل على كل Node. وظيفته هي التأكد من أن الحاويات تعمل كما هو متوقع في الPod, بيعمل دا في عدة خطوات زي التواصل مع ال Control Panel وكذلك مع الـ Container runtime وتجميع تقارير عن حالة ال Containers وإرسالها لـ Control Panel.
7- Kube-proxy: المكون المسؤول عن إدارة الشبكة وتوجيه ال traffic لل worker node وال Service الصحيحة.
8- API Server: هو العنصر الرئيسي في الـ Control Plane، ويُعتبر البوابة (Gateway) التي يتفاعل من خلالها كل شيء داخل أو خارج الـ cluster مع k8s.
9- Controller manager: هو المسؤول عن إدارة الحالة داخل الـ cluster والتأكد من أن كل شيء يعمل كما هو “مطلوب” (وفقًا لتعريفك في ملفات YAML مثل Deployments، ReplicaSets، إلخ).
10- Scheduler: مكون من مكونات الـ Control Plane بيحدد أين يجب تشغيل الـ Pods, فوقت ما تطلب إنشاء Pod جديد بيقوم ال Scheduler باختيار الـ Node المناسبة من حيث الموارد وال Constraints لإنشاء الPod.
11- ETCD: هي قاعدة البيانات الأساسية والمركزية التي يستخدمها k8s لتخزين الحالة الكاملة لـ cluster. وهي بالأساس Key-value Store لضمان البساطة والسرعة في تخزين واسترجاع بيانات الـ cluster وبتعتبر هي ال Source of truth لباقي ال Cluster.
12- Service: هي كيان بيوفّر نقطة وصول ثابتة وثابتة الاسم (Stable Endpoint) لمجموعة من الـ Pods، حتى لو تغيّرت أو أُعيد تشغيلها.لأن ال Pods لما يعاد تشغيلها ممكن ال IP الخاص بيها يتغير ووقتها أنت كمستخدم هتحتاج تغير طريقة تواصلك معها وعشان نتجنب دا بنقدم ال Service فتفضل طريقة التواصل للتطبيق أو الخدمة ثابتة بغض النظر عن تفاصيل التشغيل.
13- Kubectl: ال Command line interface الأساسية للتفاعل مع Kubernetes
14- ConfigMaps: تُستخدم لتخزين الإعدادات غير السرية للتطبيقات.
15- Secrets: تُستخدم لتخزين معلومات حساسة (مثل كلمات المرور ، مفاتيح API).
16- Ingress: هو عبارة عن Smart gateway تُستخدم لتوجيه الزيارات الخارجية (HTTP/HTTPS) القادمة من الإنترنت إلى داخل ال Cluster وتحديدًا إلى الـ Services وال Pods المناسبة.
Vodafone Big Data Services Behind The Scene
هل في مرة لاحظت إنه جالك عرض لباقة أكبر من باقتك الشهرية بسعر أقل وفي نفس الوقت اللي باقتك الشهرية قربت تخلص فيه، أو مثلًا جالك عرض لباقة يوتيوب مع إنك مش مشترك في باقة خاصة بيه ولكن فعلًا بتستعمله كتير!
قد يبدو ليك إن عروض الباقات دي هي عروض عادية أو مجرد صدفة ولكن بيكون وراها الكثير والكثير من التحليلات والخطط المُخصصة لكل عميل ؛ التحليلات دي بتبدأ من المشاكل اللي بتقابلك في Connection الشبكة لحد تقديم عروض مميزة وخاصة بيك.
Big Data Techniques
شركة كبيرة زي فودافون بتتعامل مع ملايين من العملاء، عشان تتعامل مع الداتا دي بتستعمل Big Data Techniques ودي تقنيات بتتعامل مع الداتا الكبيرة اللي التقنيات التقليدية متقدرش تتعامل معاها؛ تقنيات ال Big Data بتقوم بتخزين ومعالجة داتا العملاء باستخدام ال Distributed Systems زي Spark و Hadoop وتقنيات ال Stream Processing زي Apache .
التقنيات دي بيتم استخدامها بشكل دوري في تحليل سجلات المكالمات يوميًا مثلًا واللي بيتم تحليها لمراقبة أنماط استخدام العملاء وتحسين أداء الشبكة فيما بعد في الأوقات اللي ممكن يحصل فيها ازدحام زي أوقات الأعياد والأحداث الرياضية.
وكمان بتجمع الداتا في شكل منظم قابل إنه يدخل على تقنيات Machine Learning متقدمة لعمل تنبؤات وعمل أنظمة تساعد العميل في استفساراته اليومية بناءً على استفسارات العملاء اللي قبل كدا ودا هيتم مناقشته في الكام نقطة الجايين.
تحسين تجربة العملاء - Recommendation Systems
بداية التفكير في تحسين تجربة العميل جاية من إدراك الشركة لقيمة العميل القديم لأنه بيكون أكثر ولاء ليها وكمان بيكون سفير لخدماتها برا مع الناس الجديدة فدايمًا بتحاول الشركات عمومًا وشركات الاتصالات هنا بالأخص إنها تريّح عملائها لأن ال Customer Lifetime Value ليهم بتكون عالية؛ ودا KPI مهم لأرباح الشركة.
هنا بنستخدم تقنيات زي :
تقنية ال Neural Collaborative Filtering اللي بتستخدم ال Neural Network لفهم العلاقات بين العملاء والمنتجات اللي بيستخدموها وبتقدر تتعامل مع الداتا الكبيرة والمعقدة وأيضًا بتستخدم بشكل كبير في منصات زي Amazon و Spotify، دا عن طريق إن ال Output بتاعها بيكون بيدور حول هل العميل هيحب الاقتراح ولا لأ باستخدام ال probabilites، زي مثلًا تقدم توصية لعميل بيشوف المحتوى المرئي كتير بإنه يشترك في باقة أكبر بدل ما بفضل يجدد باقته الصغيرة كل فترة.
تقنية ال content-based Filtering ودي بتقدم توصيات بناءً على محتوى العناصر نفسها وتصنيفها زي نوع باقة معينة هتناسب استخدامك اليومي سواء كانت نت أو مكالمات وهكذا.
التقنية دي بتختلف عن التقنية الأولى في إنها بتعتمد على داتا العميل نفسه ومش بتعتمد على بيانات العملاء السابقين وبناءً على كدا بتقدم توصيات فردية ولكن ممكن تفضل تقدم نفس الاقتراحات بشكل متكرر ودا أحد عيوبها.
احتياجات العملاء المستقبلية - Demand Forecasting
فودافون بتحاول تفهم احتياجات العملاء في ال Real-time أو حتى على المدى البعيد عشان تقدر تاخد رد فعل سريع ف بتستخدم Sentiment Analysis Techniques عشان تعرف مدى رضا العميل خاصة من المحادثات اللي بتكون مع Chatbot؛ ودا AI technique معتمد على ال NLP بيحلل كلام العملاء ويصنفه لإيجابي أو سلبي وبناءً على كدا تبدأ تتصرف وتلبي الاحتياجات بشكل سريع.
ومع أخذ بيانات عملاء كثيرة في عين الاعتبار فالشركات بتستخدم التقنيات دي لتعزيز سعة الشبكة مستقبلًا في المناسبات المهمة منعًا إن أي عطل يحصل.
حماية الشركة - Infrastructure Prediction
النقاط السابقة كانت بتستهدف العميل بشكل مباشر وبتحاول تحسن علاقته بالشركة لكن هنا هنناقش دور ال Data Science وال AI في حماية الشركة نفسها والمحافظة على مواردها المختلفة.
خصم 50% على جميع خطط الاشتراك السنوية لفترة محدودة، تقدروا دلوقتي تشتركوا في اقرأ-تِك وتستمتعوا بكافة المقالات في كل ما يخص هندسة البرمجيات باللغة العربية والمحتوى المميز من ورقة وقلم ومدونات فطين اللي بيتميزوا بتصاميم ذات جودة عالية وكل ده بحرية كاملة وكمان مفاجآت اقرأ-تِك الجاية 🚀
وبرضو متاح الاشتراك من خلال InstaPay و VodafoneCash 🎁
مدونات فطين في تصميم النظم - الإصدار الأول 🚀
كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.
على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:
لماذا صُمّم هذا النظام بهذه الطريقة؟
لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟
هل كان يمكن أن نصمم الأمر بشكل أبسط؟
الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.
هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.
اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.
إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.
يتناول الكتاب ما يعادل من 15 تجربة عملية مميزة من داخل الشركات العالمية في تصميم النظم الضخمة بأكتر من 160 صفحة ويضم الآتي :
Introduction Into System Design
How Uber Serves Over 40 Million Reads Per Second
How Discord Stores Trillions of Messages
Dropbox's Chrono: Scalable, Consistent and Metadata Caching Solution
Unlocking Notion's Power - The Data Model Explained
How Shopify Mitigates Deadlocks in High Concurrency Environments
How LinkedIn Improves Microservices Performance With Protobuf
How Figma Secures Internal Web Applications
How GitHub Improves Reliability of Code Push Processing
How Meta Leverages AI For Efficient Incident Response
How Stripe Architected Massive Scale Observability Solution on AWS
Change Data Capture at Pinterest
How Canva Built Scalable and Reliable Content Usage Counting Service
How Netflix Migrates Critical Traffic at Scale With No Downtime
How Slack Handles Billions of Tasks in Milliseconds
How YouTube Supports Billions of Users With MySQL
System Design Comprehensive Guide
تقدروا تشوفوا النسخة كاملة من هنا كـ E-Book ، وحاولنا نخليها بسعر رمزي يناسب الجميع 👇
وكمان وفرناه على Kindle عشان الناس اللي بتحب تجربة القراءة على الـ Kindle منحرمهاش من التجربة الممتعة دي 🎉
بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.
دورك كشريك أو راعي هيكون محوري في دعم المحتوى وتوسيع نطاق تأثيره. فانضم لرحلتنا وكن جزءًا من صناعة مستقبل التكنولوجيا في المنطقة 🚀
تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
