CALM/arwiki huggingface dataset:
عندما كان هناك حاجة إلى التطوير، استخدام كوكوا لـ أوبجكتف سي جعل هذا مهمة بسيطة. يتضمن أوبجكتف سى مفهوم الـ "الفئات" الذي يسمح بالتعديلات لأى طبقة "إن بلايس" موجودة. الوظيفة يمكن أن تنجز في فئة بدون أى تغيرات للطبقات الرئيسية في الإطار، أو الوصول لمصدرها. كانت هذه المهمة تتطلب من المبرمج أن يعمل فئات فرعية تدعم المميزات الإضافية في الأنظمة الشائعة قبل هذا النظام، ثم يقوم بتغيير جميع نماذج الطبقة للطبقة الجديدة.
إطارات كوكوا تكتب بأوبجكتف سى، ولذلك أوبجكتف سي هي اللغة المفضلة لتطوير تطبيقات كوكوا. ارتباطات جافا لإطارات كوكوا عرفت باسم "جسر الجافا" متوفر أيضا ولكن لم تثبت شعبيته بين مطورين كوكوا. علاوة على ذلك، تعنى الحاجة إلى ربط وقت التشغيل العديد من المميزات الرئيسية لكوكوا غير متوفرة في الجافا. في عام 2005، صرحت أبل بأن جسر جافا كان مستنكر، مما يعنى أن المميزات التي أضيفت لكوكوا في إصدارات نظام التشغيل ماك إكس بعد 10.4 لم تكن أضيفت لواجهة جافا- كوكوا البرمجية.
في الأصل، ستوديو ابل سكريبت كان يمكن أن يستخدم لتطوير تطبيقات كوكوا أقل تعقيدا. ومع ذلك، كما الفهد الجليدى، كان مستنكرا. لقد استبدل بـ أبل سكريبت أو بى جى سى، والذي يسمح لك بالبرمجة في أبل سكريبت، أثناء استخدامك لإطارات كوكوا.
ارتباطات الطرف الثالث متوفرة للغات أخرى تتضمن كلوجر سي إل، ليسب وركس، باى أو بى جى سى، روبى كوكوا، كام بونز، كوكوا# ومونو أو بى جى سى وسى #. إن يو يستخدم نموذج كائنات أوبجكتف سي مباشرة، ولذلك يمكن أن يستخدم إطارات كوكوا بدون الحاجة للربط.
هناك أيضا تطبيقات مفتوحة المصدر لأجزاء رئيسية لإطارات كوكوا التي تتعامل مع أنظمة التشغيل وتتضمن مايكروسوفت ويندوز تطوير تطبيقات كوكوا، مثل جي إن يو ستيب، وكوكوترون.
مراجعة الكود هي فحص (غالبا ما يكون في شكل مراجعة الزملاء) كود مصدري للحاسب بطريقة منهجية. والغرض من هذه العملية هو اكتشاف وتصحيح خطأ برمجي تم إغفاله في مرحلة تطوير البرمجيات (علم حاسوب) الابتدائية، إضافة إلى تحسين جودة البرمجيات العامة ومهارات المطورين. وتتم المراجعات بأشكال عديدة مثل [البرمجة الثنائية pair programming]، ومراجعات البرمجيات غير الرسمية، و[الفحوصات inspections] الرسمية.
غالبا ما تمكن عملية مراجعة الكود من العثور على الثغرات الأمنية vulnerabilities و القيام بإزالتها، مثل استغلال سلسلة التنسيق غير المتحكم فيها format string exploits، وحالة سباق، و[تسرب الذاكرة] وفيض الدارئ، وبهذه الطريقة يتم تحسين أمان البرنامج. ومخازن البرامج على الإنترنت المبنية على أباتشي سبفيرجن (مع برنامج Redmine أو Trac)، وMercurial، وGit أو أدوات أخرى تسمح لمجموعات الأفراد بمراجعة الكود بشكل تعاوني. وعلاوة على هذا، فالأدوات المحددة للمراجعة التعاونية للكود يمكن أن تسهل عملية مراجعة الكود.
و[مراجعة الكود code reviewing software] الآلية تقلل من مهمة مراجعة أجزاء ضخمة من الكود التي يقوم بها مطور برمجيات من خلال مراجعة منظمة لكود المصدر بحثا عن ثغرات أمنية معروفة.
وتحليل Capers Jones المستمر لما يزيد عن 12.000 مشروع تطوير برمجيات قد أظهر أن معدل اكتشاف الخلل الكامن في الفحص الرسمي يتراوح بين 60 إلي 65%. وبالنسبة للفحص غير الرسمي، فالرقم هو أقل من 50%. ومعدل اكتشاف الخلل الكامن لمعظم أشكال الاختبار هو حوالي 30%.
والمعدلات المثالية لمراجعة الكود هي حوالي 150 سطر من الكود في الساعة. وفحص ومراجعة أكثر من بضع مئات من سطور الكود في الساعة الواحدة بالنسبة للبرامج الحاسمة (مثل [البرنامج المضمن embedded software] الحاسم للأمان) ربما يكون سريعا للغاية لدرجة أنه لا يكتشف أخطاء. وتشير بيانات الصناعة إلي أن مراجعة الكود يمكن أن تحقق على الأكثر معدل 85% لإزالة الخلل بمتوسط معدل يصل إلي حوالي 65%.
تقع ممارسات مراجعة الكود في ثلاثة تصنيفات رئيسية: البرمجة الثنائية pair programming
ومراجعة الكود الرسمية formal code review ومراجعة كود خفيفة lightweight code review..
فمراجعة الكود الرسمية، مثل [عملية تفتيش فاجان Fagan inspection]، تنطوي على عملية مفصلة وحذرة مع مشاركين متعددين ومراحل متعددة.
ومراجعات الكود الرسمية هي الوسيلة التقليدية للمراجعة، والتي فيها يحضر مطور برمجيات سلسلة من اللقاءات ويراجعون الكود سطر سطرا، وعادة ما يستخدمون نسخ مطبوعة من المادة. والفحوصات الرسمية هي شاملة للغاية وقد ثبت أنها فعالة في اكتشاف الخلل والعيوب في الكود الخاضع للمراجعة.
ومراجعة الكود الخفيفة تتطلب تكاليف أقل من فحوصات الكود الرسمية، على الرغم من أنها تساويها في الفعالية عندما تتم بشكل ملائم. وغالبا ما يتم إجراء المراجعات الخفيفة كجزء من عملية تطوير عادية:
وربما يسمى بعض هذه الأساليب "عمليات مراجعة" (غير رسمية) أو"نقد" (سريع وغير رسمي).
وكثير من الفرق التي تتحاشى استخدام مراجعة كود الزملاء التقليدية الرسمية تستخدم إحدى الأشكال المذكورة بأعلى للمراجعة الخفيفة كجزء من عمليتهم الطبيعية للتطوير. ولقد وجدت دراسة حالة لمراجعة الكود والتي تم نشرها في كتاب "Best Kept Secrets of Peer Code Review" أن المراجعات الخفيفة قد كشفت أخطاء برمجية تماثل عدد ما اكتشفته المراجعات الرسمية، إلا أنها كانت أكثر سرعة واقل تكلفة.
تاريخيا، اكتسبت مراجعات الكود استثمارا معقولا في الإعداد لحدث المراجعة وزمن التنفيذ.
ويعتقد البعض أن الاستخدام الماهر والمنضبط لعدد من أعمال التطوير يمكن أن تنتج عنه معدلات مرتفعة لاكتشاف أو تجنب الخلل الكامن. وعلاوة على هذا، فأنصار إكس بي XP(البرمجية القصوى) ربما يجادلون أن وضع ممارسات إضافية للبرمجة القصوى، مثل إعادة هيكلة الكود و[التطوير المعتمد على الفحص test-driven development] سوف يتسبب في وجود مستويات خلل كامنة تماثل ما يمكن تحقيقه من خلال المداخل الأكثر تقليدية، بدون الاستثمار.
ويمكن لاستخدام أدوات تحليل الكود أن تدعم هذا النشاط. وخاصة الأدوات التي تعمل في مجال بيئة التطوير المتكاملة IDE لأنها توفر تغذية راجعة مباشرة لمطوري تطابق معيار الكود
FLTK برنامج ذا إمكانية خاصة بالسرعة والخفة والوضوح الأدوات ذات إمكانيات واضحة وسريعة وخفيفة تعطي "علامة كاملة" وذلك عبر واجهة المستخدم الرسومية التي وضعتها مكتبة سبيتزك وغيرهم أدلى مع البرمجة 3D الرسومات في الاعتبار، ولديه واجهة لبينغل، ولكنها أيضا مناسبة لبرمجة واجهة المستخدم الرسومية بشكل عام.
استخدام القطعة الخاصة به والرسم والأنظمة الحديثة على الرغم من الوضوح والسرعة والخفة اكتسبت دعم تجريبي لاستخدام اختياريا الرسومات الخاصة بمكتبة القاهرة المستخرجة من التعليمات البرمجية التي تعتمد على النظام الأساسي، فإنه يسمح لكتابة البرامج التي تبدو متشابهة في جميعأنظمة التشغيل المعتمدة
برنامج ذات الوضوح والسرعة والخفة هومن البرمجيات الحرة والمرخص لها بموجب غبل مع شرط إضافي يسمح ربط ثابت من التطبيقات مع التراخيص غير المتوافقة ويشمل السائل مصمم واجهة المستخدم وهو مصمم واجهة المستخدم الرسومية الذي يولد سي + + مصدر ورأس الملفات.
وعلى النقيض من المكتبات مثل كيو تي والتطبيقات المصغرة، برنامج اف تي كي ال يستخدم تصميم أكثر خفة في الوزن تقييد نفسه إلى وظائف واجهة المستخدم الرسومية. وبسبب هذا، ومكتبة صغيرة جدا (برنامج اف تي كي ال "مرحبا العالم" البرنامج حوالي 100 كيلوبايت)، وعادة ما تكون مرتبطة بشكل ثابت. كما أنه يتجنب تعقيد وحدات الماكرو للمعالجة البرمجية المنفصلة ولا يتم استخدام سي + + ذات الميزات المتقدمة : القوالب، والاستثناءات، أو ر ت ت ل أو FLTK1.x مساحات جنبا إلى جنب مع تواضع حجم الحزمة، وهذا يؤدي إلى منحنى تعليم قصير نسبيا للمستخدمين الجدد.
هذه المزايا تأتي مع عيوب المقابلة. لبرنامج FLTK لعروض أقل من التطبيقات المصغرة معظم الأدوات لواجهة المستخدم الرسومية، وذلك بسبب استخدامه من أزرار غير أصلية، وليس لديه نظرة الأم ولا يشعر بأي نظام أصلي.
FLTK ماذا يعني برنامج?
برنامج إف ال تي كي كان مصمما أصلا ليكون متوافق مع مكتبة من نماذج مكتوبة لآلات (مشتقة من هذه المكتبة تسمى "إشكال اكس"و لا تزال تستخدم في كثير من الأحيان). في تلك المكتبة في جميع المهام والهياكل مع "fl_". وقد مددت هذه التسمية على جميع الوسائل جديدة والحاجيات في مكتبة سي + +، وهذه كانت البداية لفلوريدا"التي اتخذ منها مثل اسم المكتبة. بعد صدور فلوريدا التي مفتوحة المصدر اكتشف انه من المستحيل البحث في "فلوريدا"على شبكة الإنترنت، ويرجع ذلك إلى حقيقة أنها هي أيضا اختصار عن ولاية فلوريدا. بعد الكثير من النقاش والبحث عن اسم جديد لمجموعة الأدوات، التي كانت قيد الاستخدام من قبل عدة أشخاص، وجاء بيل مع برنامج FLTK الذي يتميز بسرعة وخفة مجموعة الأدوات
استخدام برنامج FLTK في لغات البرمجة.
قد صمم أساسا ليكتب في، سي + + كلغة برمجة. ومع ذلك، ارتبط بوجود لغات أخرى، على سبيل المثال بيثون، [3] لوا [4])، وروبي. [5]
المثال التالي لبرنامج FLTK 1.x يخلق نافذة مع زر "اوكي" :
int main(int argc, char *argv[]) {
Fl_Window* w = new Fl_Window(330, 190);
new Fl_Button(110, 130, 100, 35, "Okay");
w-&gt;end();
w-&gt;show(argc, argv);
return Fl::run();
برامج مبنية على برنامج FLTK.
ويستند البرنامج علي جدول أعمال لينكس المستندة إلى المساعد الرقمي الشخصي على برنامج FLTKوكذلك الكثير من البرامج وضعت لذلك من قبل أطراف ثالثة
تاريخ الإصدار يبين المصدر المفتوح لبعض الطبيعة المضطربة للتنمية.
101x.
هذه هي النسخة السابقة المستقرة ولم يعد يحافظ عليها.
102x.
هذه هي النسخة راسخة ومستقرة، ومحافظ عليها في الوقت الحالي.
2,0 فرع.
لبرنامج FLTK وكان هذا الفرع الخاص بالتنمية، وبعد طول تفكير أن تكون الخطوة التالية في التطور، مع العديد من الميزات من حيث البرمجة الجديدة وأسلوب البرمجة الأنظف انها لم تحقق الاستقرار والتنمية وتوقفت إلى حد كبير.
1.2.x.
وكانت هذه محاولة لاتخاذ بعض أفضل الميزات من 2,0 ودمجها مرة أخرى إلى فرع 1,1 أكثر شعبية ولم تعد في المتقدمة.
1.3.x.
هذا هو المكان الذي وضع على أحدث طبعة رئيسية قادمة من برنامج FLTK إلا أنه إلى حد ما أقل طموحا من 2,0 كان، أشبه 1,1 ولكن لا يزال على استعداد لكسر واجهات برمجة التطبيقات لإضافة ميزات جديدة.
فرع 3,0.
هذا الفرع هو في الغالب نموذج نظري للعمل في المستقبل.
البرمجة الزوجية هي أحد تقنيات أجيل لتطوير البرمجيات حيث يعمل اثنين من المبرمجين معا في محطة عمل واحدة. يكتب أحدهم الكود المصدري في حين يستعرض الأخر كل سطر من الأكواد كما تمت كتابتها. والشخص الذي يقوم بالكتابة يُسمى المحرك. ويطلق على الشخص الذي يستعرض الكود المراقب (أو الملاح). ويتبادل المبرمجان الأدوار بشكل متكرر.
أثناء الاستعراض، يضع المراقب في اعتباره التوجه الاستراتيجي للعمل، والخروج بأفكار من أجل إدخال تحسينات والمشاكل المحتملة في المستقبل لمعالجتها. وهذا يتيح الفرصة للمحرك في تركيز كل اهتمامه على الجوانب "التكتيكية" لاستكمال المهمة الحالية، وذلك باستخدام المراقب كشبكة أمان ودليل.
وجدت بعض الدراسات أن المبرمجين الذين يعملون بشكل زوجي ينتجون برامج أقصر، مع تصميمات أفضل وعدد أخطاء برمجية أقل، من المبرمجين الذين يعملون وحدهم. وقد وجدت الدراسات انخفاض معدلات الخطأ من 15 ٪ إلى 50 ٪، وتتفاوت اعتمادا على خبرة المبرمج وتعقيد المهمة. وعادة ما ينظر الأزواج في بدائل تصميمية أكثر من المبرمجين المنفردين، ويستطيعوا التوصل إلى تصاميم أكثر بساطة وأكثر ثباتا؛ كما يستطيعون اصطياد عيوب التصميم في وقت مبكر. وعادة ما يعمل الأزواج بشكل أسرع من مبرمج واحد مخصص لنفس المهمة. وغالبا ما يجد الأزواج المشاكل التي تبدو "مستحيلة" سهلة أو حتى سريعة الحل، أو على الأقل من الممكن حلها عندما يعملون معا.
ومع ذلك، وفي 2007، استنتج تحليل الميتا أن "البرمجة الزوجية ليست مفيدة بشكل موحد أو فعالة" بسبب أن العديد من العوامل الأخرى بجانب اختيار استخدام البرمجة الزوجية لها آثار كبيرة على نتائج مهمة البرمجة. ووجدت دراسة الميتا أن البرمجة الزوجية تميل إلى تقليل الوقت اللازم للتطوير، وتنتج آثارا إيجابية هامشية على نوعية الكود، ولكن هذه البرمجة الزوجية تتطلب جهد أكبر من المطور، وهذا يعني، أن تكلفتها أكثر بكثير من تكلفة البرمجة المنفردة. ويقترح المؤلفان أن دراسة البرمجة الزوجية تعاني من التحيز في النشر حيث ان الدراسات التي لا تظهر أن البرمجة الزوجية مفيدة، لا تقدم للنشر، أو لا يقبل نشرها. وبالتالي يتم الاستنتاج أنه "لا يمكنك ان تتوقع أسرع وأفضل وأرخص".
على الرغم من اكتمال الترميز بشكل أسرع مما يكون عليه عندما يعمل مبرمج واحد وحده، فإن مجموع وقت المبرمج (عدد المبرمجين × الوقت الممضى) يزداد. ويجب على المدير أن يوازن بين انتهاء العمل بشكل أسرع وتقليل الاختبار ووقت التصحيح ضد ارتفاع تكلفة الترميز. ويمكن للوزن النسبي لهذه العوامل أن تختلف من مشروع إلى آخر ومهمة لأخرى. ان الاستفادة من الاقتران هو أعظم بالنسبة للمهام التي لا يستعبها المبرمجين تماما قبل أن البدء: وهذا يعني، المهام الصعبة التي تدعو إلى الإبداع والتطور.
المَامِيثَا الصفراء نوع نباتي يتبع جنس الماميثا من الفصيلة الخشخاشية.
ينتشر في كافة أنحاء حوض البحر الأبيض المتوسط وأوروبا بما في ذلك المشرق العربي والمغرب العربي. يوجد أيضاً في الأمريكتين وأستراليا.
المَامِيثَا الأفغانية نوع نباتي يتبع جنس الماميثا من الفصيلة الخشخاشية.
المَامِيثَا البرتقالية نوع نباتي يتبع جنس الماميثا من الفصيلة الخشخاشية.
المامِيثَا الحلبية نوع نباتي يتبع جنس الماميثا من الفصيلة الخشخاشية.
ينتشر في المشرق العربي.
المامِيثَا الأنطالية نوع نباتي يتبع جنس الماميثا من الفصيلة الخشخاشية.
ينتشر في جنوب تركيا.
يونتي هي واجهة شل لبيئة سطح المكتب جنوم طورت من طرف كانونيكال ليمتد لصالح نظام التشغيل أوبونتو.يونتي بدأت مع إصدار نتبوك أوبونتو 10.10
وهي مصممة لاستخدام أكثر فعالية للمساحة نظراً لصغر حجم شاشة النتبوك بما في ذلك
على سبيل المثال، تبديل التطبيقات عموديا. خلافا لجنوم تجميعة البرامج KDE أو إكس إف سي إي ، يونتي ليست تجميعة تطبيقات وإنما صممت لتستعمل مع برامج +GTK.
تعتبر يونتي جزء من مشروع Aytana project ،و هي مبادرة لتحسين تجربة المستخدم في أوبونتو.بالإضافة إلى يونتي هناك مؤشرات التطبيق وغيرها من المشاريع مثل MeMenu، ونظام الإخطار notification system وNotifyOSD.
من تقاليد أوبونتو استخدام بيئة سطح المكتب جنوم الكاملة، المؤسس مارك شاتلوورث يبين الاختلافات الجوهرية مع مجموعة جنوم من خلال تجربة المستخدمين ليشرح لماذا أوبونتو سيستعمل يونتي كسطح مكتب افتراضي بدلا من جنوم ابتداء من أبريل 2011 مع أوبونتو 11.04.
في نوفمبر 2010 اوضح مدير مجتمع اوبونتو جونو بايكون أن أوبونتو سيواصل دعم جنوم ومختلف تطبيقاته، وأن أوبونتو الأمثل لجنوم. والفرق الوحيد كما يقول يمكن أن يونيتي شل مختلف عن جنوم.
أعلنت كانونيكال أنها طورت يونتي هندسيا لتعمل على أجهزة سطح المكتب مع جعلها الشل الافتراضي لأوبونتو نسخة 11.04.
جنوم غير مدمجة في أوبونتو 11.04،لأنه لم يتم الانتهاء من العمل على ذلك في الوقت الذي تم تجميد النسخة 11.04،لكنها ستكون متاحة عبر حزمة الأرشيف الشخصية،و يتوقع أن يكون ذلك في أوبونتو 11.10.
في نوفمبر 2010،أعلن مارك شاتلوورث عن وجود نية لتشغيل يونتي في نهاية المطاف على نظام وايلاند بدلا من النظام القائم حاليا باستخدامها نظام النافذة اكس .
يونتي ودعم مشروع Ayatana موجهة أساسا لأوبونتو، فبالتاي كل الإصدارات الجديدة تعرض على اوبونتو.
خارج اوبونتو، حاولت توزيعات أخرى من لينكس ادماج يونتي بدرجات متفوتة من النجاح فمكونات Ayatana تتطلب تعديلات على مختلف التطبيقات الأخرى، مما يزيد من صعوبة وتعقيد دعمها من قبل المنصات الأخرى.
يونتي مقابل يونتي ثنائية الابعاد.
حافظت كانونيكال على نسختين منفصلتين من يونتي يكاد لا يمكن التفريق بينهما بالعين المجردة ولكن هما مختلفتان كليا من الناحية التقنية.
يونتي مبرمجة كإضافة في compiz ومكتوبة بلغة سي ++ وفالا وتستعمل نوع من مكتبة الرسوميات المفتوحة غير معروف بكثرة يسمى نيكس هذه الإضافة تعطي ليونتي تسارع للجرافيك متوافق مع الأنظمة.
يونتي ثنائية الابعاد هي مجموعة من التطبيقات المنفردة.و هي مكتوبة بلغة واجهة المستخدم الرسومية QML بناء على بيئة كيوتي .افتراضيا يونتي ثنائية الأبعاد تستخدم مدير النوافذ ميتاسيتي و لكن يمكن أن تستخدم مير نوافذ متسارع مثل كومبيز أو كوين .
يونتي ثنائية الأبعاد ستعوض بيئة سطح المكتب جنوم الكلاسيكية ودعم للمستخدمين الذين لا تستطيع أجهزتهم تشغيل يونتي ثلاثية الأبعاد، ابتداءً من اوبونتو 11.10.
يونتي عبارة عن برنامج مجاني صدر تحت شروط ترخيص جنو العمومية ر ج ع إ3 ورخصة جنو العمومية الصغرى ر ج ع ص إ3 على الرغم من هذا فإن برنامج يونتي يخضع لشروط استخدام كانونيكال ليمتد،مما يتطلب المساهمة لإعطاء شروط الاستخدام وهو ما يتيح لكانونيكال اصدار يونتي تحت تراخيص مختلفة.
إن تصميم وطريقة عمل يونتي كانا مثيرين للجدل منذ البداية ونتيجة لذلك فقد كتب العديد من مقيمي البرامج والخبراء حول الموضوع باحثين عن الأخطاء الموجودة فيها ومحاولين ابراز محدوديتها، وبالرغم من ذلك هناك من الخبراء من اعتبر هذا المشروع هو تحسن وتقدم نحو جنوم 2 مما يزيد من احتمال تحسين وتطوير يونتي عبر الوقت.
بعد وقت قصير من كشف النقاب عن إصدار مبكر جدا من يونتي في صيف عام 2010، لاحظ بول ريان من آرس تكنيكا ظهور مشاكل في طريقة تشغيل التطبيقات الإضافية التي ليست على شريط التطبيقات. وأشار أيضا إلى عدد من الأخطاء، بما في ذلك عدم وجود وسائل لتعقب التطبيقات التي كانت مفتوحة، جنبا إلى جنب مع غيرها من التعديلات.ولاحظ أن العديد من هذه الأخطاء ترجع على الأرجح إلى مرحلة مبكرة في عملية التطوير وتوقع ان تتحسن بمرور الوقت. واختتم بول إيجابيا، "تجربتنا لنموذج من يونتي يقودنا إلى الاعتقاد بأن المشروع يتمتع بإمكانات كبيرة ويمكن أن يجلب الكثير من القيمة إلى الإصدار النتبوك لأوبونتو.أسلوب بصري فريد من نوعه بخلطة جميلة مع أوبونتو الافتراضي الجديد ونموذجها التفاعل الأساسي يبدو مقنع ومناسب تماما للشاشات الصغيرة.
المامِيثَا الرمادية نوع نباتي يتبع جنس الماميثا من الفصيلة الخشخاشية.
المامِيثَا العربية نوع نباتي يتبع جنس الماميثا من الفصيلة الخشخاشية.
ينتشر في جنوب غرب المشرق العربي وفي الحجاز في الجزيرة العربية.
المامِيثَا مدببة الأسنان نوع نباتي يتبع جنس الماميثا من الفصيلة الخشخاشية.
ينتشر في وسط الأناضول.
المَامِيثَا الأنيقة نوع نباتي يتبع جنس الماميثا من الفصيلة الخشخاشية.
موطنه المغرب العربي ومصر وبلاد الشام والقوقاز إضافة إلى أفغانستان وطاجكستان وباكستان وإيران.
المَامِيثَا كبيرة الأزهار نوع نباتي يتبع جنس الماميثا من الفصيلة الخشخاشية.
موطنها مناطق بلاد الشام ومصر وتركيا والقوقاز.
أزهر العبيدي (1946م) هو كاتب ومؤرخ موصلي.
هو أزهر سعد الله خليل حياوي العبيدي، أنهى دراسته الأولية في الموصل عام 1962 التحق بالكلية العسكرية عام 1964، عين في صنف المدفعية عام 1967. دخل كلية الأركان وتخرج فيها عام 1978. اشترك بدورة الدفاع الوطني في جامعة البكر للدراسات العسكرية العليا وحصل على دبلوم عال عام 1989 شغل عدة مناصب في الجيش آخرها قائد فرقة المشاة. واحيل على التقاعد عام 1991.عضو في اتحاد الأدباء والكتاب. وعضو في جمعية المؤرخين، وعضو في جمعية النسابين.
وله مؤلفات مخطوطة منها: مذكرات قائد فرقة عراقي (3 أجزاء) العسكرية الحقيقية، الحرب العراقية الإيرانية، حرب الخليج الثانية.
في علم الحاسوب وهندسة البرمجيات، يعد مصطلح قابلية إعادة الاستخدام (Reusability) هو عبارة عن جزء من شفرة يمكن استخدامها مرة أخرى لإضافة وظائف جديدة مع تعديلات طفيفة أو بلا تعديلات إطلاقا. الوحدات والفئات القابلة للاستخدام مرة أخرى تقلل وقت التنفيذ وتزيد من احتمالية أن تزيل الاختبارات والاستخدامات المسبقة كافة الفيروسات وتقوم بتوطين تعديلات الشفرات حين يكون هناك حاجة للتغيير في طريقة التنفيذ.
وتعد الوظائف الروتينية الفرعية أو الوظائف عامة هي أبسط أشكال إعادة الاستخدام. يتم ترتيب قدر من الشفرة بصورة منتظمة باستخدام البرمجة التركيبية أو مساحات الأسماء في صورة طبقات. ويدعي المؤيدين لهذه الطريقة أن تلك كائن (علوم الحاسوب) ومكونات البرمجيات تقدم شكلا أكثر تطورا من القابلية لإعادة الاستخدام على الرغم من أنه أصبح من الصعب قياس وتحديد المستويات أو درجات القابلية لإعادة الاستخدام بشكل موضوعي.
إن القدرة على إعادة الاستخدام تكمن في طريقة جوهرية حول القدرة على بناء أشياء أكبر من أجزاء صغيرة والقدرة على تحديد الأمور الشائعة بين هذه الأجزاء. وغالبا ما تكون القابلية لإعادة الاستخدام صفة مرغوب فيها لبرنامج منصة حاسوب. إن قابلية إعادة الاستخدام تتيح مجموعة من الملامح تطوير البرمجيات (علم حاسوب) التي لا تحتاج إلى النظر في أمرها حين لا تكون قابلية إعادة الاستخدام أمرا مطلوبا.
وتتضمن القابلية لإعادة الاستخدام بعض الإدارة الواضحة لموضوعات البناء وتغليف والتوزيع والتركيب والتثبيت والنشر والصيانة وترقية. إذا لم يتم أخذ هذه المسائل في عين الاعتبار فربما يبدو عالم البرمجيات قابلا للاستخدام مرة أخرى من وجهة نظر التصميم ولكنه لن يكون قابلا للاستخدام مرة أخرى من الناحية العملية.
وتشير قابلية إعادة استخدام البرمجيات مرة أخرى إلى سمات التصميم لعنصر من عناصر البرنامج بشكل خاص (أو مجموعة من عناصر البرامج) التي تعزز ملاءمته لإعادة الاستخدام.
وقد تم تطوير العديد من مبادئ تصميم إعادة الاستخدام في ورش عمل WISR:
http://www.umcs.maine.edu/~ftp/wisr/SEN-pap/node1.html
سمات التصميم المرشحة لإعادة استخدام البرمجيات تتضمن:
ولم يتم التوصل إلى أي إجماع حول هذه القائمة بعد شأن الأهمية النسبية للمدخلات أو للموضوعات التي تجعل كل واحدة من هذه العناصر هامة بالنسبة لفئة محددة من التطبيقات.
يشير مصطلح الفحص في هندسة البرمجيات إلى [مراجعة زميل] أي منتج عمل من جانب أفراد مدربين يبحثون عن العيوب باستخدام عملية محددة جيدًا. كما يمكن الإشارة إلى عملية الفحص بوصفها [فحص فاغان] بحسب مايكل فاغان، منشئ العملية الشهيرة لفحص البرمجيات.
تمثل عملية الفحص أكثر أنواع ممارسات المراجعة شيوعًا الموجودة في مشاريع البرمجيات. ويتركز هدف عملية الفحص في وصول كافة مسؤولي الفحص إلى إجماع حول منتج عمل والموافقة عليه للاستخدام في المشروع. وتشمل منتجات العمل التي يشيع فحصها مواصفات متطلبات البرمجيات وخطط الاختبار. ويُحدّد منتج العمل في عملية الفحص للمراجعة ويتم جمع الفريق من أجل عقد اجتماع فحص لمراجعة منتج العمل. ويتم اختيار وسيط لترأس الاجتماع. ويحضر كل مسؤول فحص للاجتماع من خلال قراءة منتج العمل وتدوين كل عيب. والهدف من عملية الفحص هو تحديد العيوب. ويُعرّف العيب في أية عملية فحص على أنه أي جزء من منتج العمل يحول دون موافقة مسؤول الفحص عليه. على سبيل المثال، إذا كان الفريق يقوم بفحص مواصفات متطلبات البرمجيات، فسيكون كل عيب عبارة عن نص في المستند الذي يعارضه مسؤول الفحص.
وضع مايكل فاغان عملية الفحص في أواسط سبعينيات القرن العشرين، وقد شهدت العملية توسعًا وتعديلاً لاحقًا.
ومن المفترض أن يكون للعملية معايير إدخال تحدد ما إذا كانت عملية الفحص جاهزة للشروع فيها. ويحول هذا دون دخول منتجات العمل غير المكتملة في عملية الفحص. وربما تكون معايير الإدخال عبارة عن قائمة مراجعة تتضمن بعض المصطلحات مثل «تم إجراء تدقيق إملائي للمستند».
ونورد فيما يلي مراحل عملية الفحص: التخطيط، الاجتماع لإلقاء نظرة شامل، الإعداد، اجتماع الفحص، إعادة العمل والمتابعة. ينبغي تكرار مراحل الإعداد واجتماع الفحص وإعادة العمل.
يقوم الوسيط بإنهاء العملية عندما تفي ببعض معايير الإنهاء المحددة مسبقًا.
قواعد الفحص.
تُستخدم القواعد التالية خلال عملية الفحص.
أنواع الفحص ذات الصلة.
مراجعة الكود.
يمكن إجراء [مراجعة الكود] كنوع خاص من الفحص يقوم فيه الفريق بفحص عينة كود وإصلاح أي عيوب بها. والعيب في أية مراجعة للكود عبارة عن مجموعة كود لا تطبّق على نحو ملائم متطلباتها أو التي لا تعمل كما يريد المبرمج أو التي تعد غير صحيحة ولكن يمكن تحسينها (على سبيل المثال، يمكن جعلها مقروء أكثر أو يمكن تحسين أدائها). وإضافة إلى مساعدة الفريق في إيجاد الأخطاء وإصلاحها، تعد مراجعات الكود مفيدة لكل من المبرمجين ذوي التدريب المتقاطع على الكود الذي يجري مراجعته ولمساعدة صغار المبرمجين في تعلم تقنيات البرمجة الجديدة.
مراجعات الزملاء.
تعتبر [مراجعات الزملاء] أفضل ممارسة في هذا المجال لاكتشاف عيوب البرمجيات وتعلم كيفية تدوين عناصر البرمجيات. تتألف مراجعات الزملاء من [عمليات الفحص العابر للبرمجيات] وعمليات فحص البرمجيات وتعد مكملة للأنشطة الهندسية الخاصة بإنتاج البرمجيات. وتيسّر مجموعة من المعرفة والمهارات والسلوكيات المتناسقة أفضل ممارسة محتملة لمراجعات الزملاء. وتتضمن عناصر مراجعات الزملاء عملية المراجعة الهيكلية ومعيار قوائم مراجعة المنتجات المتميزة والقواعد المحددة للمشاركين والنماذج والتقارير.
وتمثل عمليات فحص البرمجيات الشكل الأكثر دقة من مراجعات الزملاء وتستخدم هذه العناصر بشكل كامل في اكتشاف العيوب. وتتذكر عمليات الفحص العابر للبرمجيات العناصر بصورة انتقائية في مساعدة المُنتِج في الحصول على أعمق فهم للعنصر والوصول إلى إجماع بين المشاركين. وتوحي النتائج المُقاسة أن مراجعات الزملاء تنتج عائد استثمار جذاب يتم الحصول عليه من خلال التعلم المتسارع والاكتشاف المبكر للعيب. وللحصول على أفضل النتائج، يتم نشر مراجعات الزملاء داخل أية مؤسسة من خلال برنامج محدد لإعداد سياسة وإجراء وتدريب الممارسين والمديرين وتحديد القياسات وملء بنية قاعدة بيانات وتعزيز البنية التحتية المنشورة.
تركيب النظم في هندسة تطبيقية هو جمع مكونات نظام في نظام واحد والتأكد من أن النظم الفرعية تعمل معا كنظام واحد. أما في تقنية المعلومات فإن تركيب النظم هي عملية ربط نظم الكمبيوتر المختلفة مع بعضها البعض وتطبيقات البرامج ماديا أو وظائفيا,
لتعمل معا كوحدة منسقة واحدة.
أداة تركيب النظام تجمع معا كافة النظم الغير مترابطة باستخدام مجموعة متنوعة من التقنيات مثل شبكة حاسوب، وتركيب تطبيقات الشركة وإدارة عجلة العمل أو برمجة يدوية
هندسة أنظمة هو عبارة عن مجموعة من النظم الفرعية التي تتعاون معا بحيث يصبح النظام قادرا على تحقيق وأداء الوظيفة. ويتضمن تركيب النظام تركيب النظم الفرعية المتواجدة (المتفاوتة غالبا). وتتمتع النظم الفرعية بسطح بيني. ويتضمن التركيب ربط النظم الفرعية مع بعضها البعض عبر "لصق" الأسطح البيانية معا. إذا لم تتشابك الأسطح البينية معا بشكل مباشر، فإن "اللصق أو الرابط" بينهما يمكن أن يوفر رسم الخرائط المطلوب. يدور تركيب النظام حول تقرير "الرابط" المطلوب.
تركيب النظام يدور أيضا حول إضافة قيمة للنظام، الإمكانات الممكنة بفضل التفاعل بين النظم الفرعية.
في عالم اليوم المترابط يصبح دور مهندسي تركيب النظم أكثر وأكثر أهمية: يتم تصميم المزيد والمزيد من الأنظمة لربطها معا داخل النظام الذي لا يزال تحت الإنشاء وللنظم التي تم نشرها أيضا بالفعل.
المهارات المطلوبة.
يحتاج مهندس تركيب النظم نطاق واسع من المهارات ويمكن بصورة كبيرة تحديدها عبر مجموعة من المعارف بصورة عرضية وليس بصورة عميقة. ومع بذل الجهد لتحديد كمية المهارات المطلوبة لأداة دمج المكونات بمعايير اليوم، فقد قام إيريك ويك بتطوير نموذج مصفوفة عام 2010 لتقييم إمكانات المكملات المهتمة بمتبعة المهن في هذا المجال.
وفي الغالب تتضمن هذه المهارات هندسة البرمجيات وعتاد الحاسوب و بروتوكولات ميفاق اتصالات الأسطح البينية ومهارات حل المشكلات العامة. وفي الغالب فإن المشاكل التي تحتاج إلى حل لم يتم حلها من قبل إلا من الناحية العرضية. كما أنه من المحتمل أن تشمل مشاكل جديدة وأكثر تحديا مع مدخل من نطاق واسع من المهندسين حيث يقوم مهندس تركيب النظام ي"بجمع كافة المطلوبات معا".
وسائل التركيب.
التركيب العمودي ( على عكس "الأفقي") هي عملية تركيب النظم الفرعية طبقا لوظيفيتها عبر صنع وحدات وظيفية يشار إليها أيضا باسم السلوات Silos. وتكمن فائدة هذه الوسيلة في أن التركيب يتم بسرعة ويتضمن فقط الباعة الضروريين، لذلك تعد هذه الوسيلة أرخص على المدى القصير. من الناحية الأخرى يمكن أن تكون تكلفة الملكية أعلى بدرجة واضحة مما في الوسائل الأخرى نظرا لأنه في حالة الوظيفية الجديدة أو المعززة تكون الطريقة الممكنة الوحيدة للتنفيذ (قياس النظام) هي عبر تطبيق السلوات الأخرى. إعادة استخدام النظم الفرعية لخلق وظيفية أخرى غير ممكن.