Payamvdn/NorthPersian_fa_wiki huggingface dataset:
شاهدان ()(به انگلیسی The Witnesses) فیلمی درام به کارگردانی آندره تشینه که در سال ۲۰۰۷ منتشر شد. با بازی میشل بلان، سامی بواجیله امانوئل بئار، ژون لیبرو؛ فیلم در سال ۱۹۸۴ در پاریس تنظیم شده و زندگی گروهی از دوستان نزدیک، که با شیوع ناگهانی اپیدمی ایدز روبرو هستند را بررسی می کند. شاهدان مورد تحسین منتقدان قرار گرفت. موسیقی. امتیاز اصلی این فیلم آلن سرده آهنگساز فیلم های آندره تشینه است. آهنگ صوتی شامل یک مجموعه متمایز از هنرمند و سبک مانند: دریافت. این فیلم توسط منتقدان مورد تحسین قرار گرفت. گوجه فرنگی گندیده گزارش می دهد که ۸۸ درصد از منتقدان این فیلم را بر اساس ۴۸ نظرسنجی مثبت ارزیابی کرده اند. نمره متاکریتیک رتبه ۷۵ را دارد. انتشار دی وی دی. این فیلم در تاریخ ۲۴ ژوئن ۲۰۰۸ در ایالات متحده منتشر شد.
ابوسهل احمد بن حسن حمدوی (همچنین حمدونی و حمدویی نیز گاهی تلفظ می گردد) ادیب، دیوان سالار و از وزیران ایرانی تبار دربار غزنویان در زمان سلطنت محمد و مسعود غزنوی بود.او ابتدا وزیر محمد بن محمود بود ولیکن یاران نزدیک محمد با مسعود تبانی کرده و همدست او شدند و محمد را کور کردند.وزیر اول مسعود جیهانی بود که در ۴۲۴ هجری فوت کرد. مسعود ابو سهل را ناظر بر کارهای تاش فراش قرار داد و او در نهایت عدل و تدبیر این وظیفه را انجام داد خانواده. چنان که از یکی از قصاید فرخی سیستانی برمی آید او برآمده از یکی از خاندان های ثروتمند و کهن ایران باستان بوده است و کاخ خاص خود را نیز داشته است که فرخی سیستانی آن را بهتر از طاق کسری توصیف می کند.
توسعه رفتارمحور در مهندسی نرم افزار، یک فرایند توسعه نرم افزار است که از توسعه آزمون محور مشتق شده است. توسعه رفتار محور تکنیک ها و قواعد اساسی، توسعه آزمون محور را با ایده های طراحی دامنه محور و تجزیه و تحلیل و طراحی شی گرا ادغام می کند تا برای تیم های توسعه و مدیریت نرم افزار، ابزارها و فرایندهای مشترکی برای همکاری در توسعه نرم افزار ارائه کند. اگرچه این فرایند، عمدتاً ایده ای در مورد چگونگی مدیریت توسعه نرم افزار با در نظر گرفتن منافع تجاری و بینش فنی است، لیکن در عمل، استفاده از ابزارهای نرم افزاری تخصصی را برای حمایت از روند توسعه در نظر می گیرد. اگر چه این ابزارها اغلب به طور خاص برای استفاده در پروژه های ت.ر. م طراحی شده اند، اما آن ها می توانند به عنوان انواع متفاوتی از ابزارهایی که از توسعه مبتنی بر تست پشتیبانی می کنند دیده شوند. این ابزارها برای اضافه کردن اتوماسیون به زبان فراگیری که موضوع مرکزی ت.ر. م می باشد به خدمت گرفته می شوند. توسعه رفتار محور تا حد زیادی با استفاده از یک روش سادهٔ زبان مختص دامنه از طریق بهره گیری از ساختارهای زبان طبیعی (از جمله جمله های انگلیسی مانند) که می تواند رفتار و
نتایج مورد انتظار را بیان کند، میسر می شود. برای مدت طولانی «تست اسکریپت»ها به عنوان یک ابزار فراگیر برای درجه های مختلفی از پیچیدگی DSLها مورد استفاده بوده اند. توسعه رفتار محور یک تجربه فنی اثر بخش به حساب می آید، به خصوص هنگامی که «فضای مسئله» کسب و کار مورد نظر پیچیده است. تاریخچه. توسعه رفتار محور مبتنی بر توسعه تست محور است. توسعه ای که از یک اسکریپت ساده در زبان مختص دامنه استفاده می کند. این DSLها جمله های زبان طبیعی را به واحدهای اجرایی آزمایشی تبدیل می کنند. نتیجه کار ایجاد یک همبستگی نزدیکتر بین معیار پذیرش برای یک تابع مشخص و تست هایی است که برای تأیید این قابلیت استفاده می شود. به همین منوال، به طور کلی توسعه رفتار محور یک گسترش طبیعی برای آزمایش های توسعه آزمون محور (TDD) می باشد. تمرکز اصلی توسعه رفتار محور بر موارد زیر است: در قلب توسعه رفتار محور یک بازخوانی دربارهٔ رویکرد واحد تست و آزمون پذیرش وجود دارد که به طور طبیعی با این مسائل همراه هستند. به عنوان مثال، ت.ر. م پیشنهاد می کند که عناوین تست واحد، جمله های کاملی باشند که با یک عبارت شرطی آغاز می شوند (به عنوان مثال "باید" به زبان فارسی)
و باید به ترتیب ارزش کسب و کار نوشته شود. آزمون پذیرش باید با استفاده از چارچوب استاندارد یک داستان کاربر تهیه گردد: "به عنوان یک [نقش] من خواستار [ویژگی] هستم به طوری که [بهره]". معیارهای پذیرش باید به در قالب سناریو نوشته شده و به صورت کلاس پیاده سازی شوند: با توجه به [وضعیت اولیه] زمانی که [رویداد رخ می دهد] باید [اطمینان از برخی از نتایج]. با شروع از این نقطه، بسیاری از افراد در طول سالیان چهار چوب هایی برای ت.ر.م طراحی کرده اند که در نهایت آن را به عنوان یک چارچوب ارتباطی و همکاری برای توسعه دهندگان، تضمین کنندگان کیفیت و شرکای غیرفنی یا ذینفعان کسب و کار در یک پروژه نرم افزاری شکل داده اند. در کنفرانس یک روزه "Agile Specifications, BDD and Testing eXchange" در نوامبر ۲۰۰۹ در لندن شمالی تعریف زیر برای ت.ر.م ارائه شد: توسعه رفتار محور (ت.ر. م) یک روش چابک نسل دوم، یکپارچه، مبتنی بر کشش، چند مالکه و متشکل از مقیاس چندگانه، با قابلیت خودکار سازی بالاست. ت.ر. م یک چرخه تعاملات با خروجی های تعریف شده را توصیف می کند، که در نتیجه تحویل کار، نرم افزار مورد آزمایش قرار می گیرد.دن نورس چهارچوب مبتنی بر توسعه رفتا
ر محور JBehave، را ایجاد کرد که توسط یک چهارچوب ت.ر. م در سطح داستان برای Ruby دنبال شده که RBehave نام دارد که بعدها به پروژه RSpec پیوست. او همچنین با David Chelimsky, Aslak Hellesøy و دیگران برای توسعه RSpec و همچنین نوشتن کتابی با عنوان "Behaviour Driven Development with RSpec, Cucumber, and Friends" همکاری کرد.Tاولین چارچوب مبتنی بر داستان در RSpec بعدها جایگزین Cucumber شد که توسط Aslak Hellesøy توسعه داده شد. Capybara، که بخشی از چارچوب آزمون Cucumber است، یکی از نرم افزارهای تحت وب اتوماسیون آزمون است. اصول توسعه رفتار محور. توسعه مبتنی بر تست یک روش توسعه نرم افزاری است که اساساً بیان می کند برای هر واحد نرم افزاری یک توسعه دهنده نرم افزار باید: این تعریف از آنجا که تست ها را از لحاظ الزامات نرم افزاری سطح بالا، جزئیات فنی ریز یا هر چیز دیگر در بین آن ها تبیین می کند نسبتاً غیر اختصاصی است؛ بنابراین، از این نقطه نظر می توان به ت.ر. م نگاه کرد که که ت.ر. م ادامه توسعه TDD است که انتخابهای ویژه تری نسبت به TDD دارد. توسعه رفتار محور مشخص می کند که آزمایش های هر واحد نرم افزاری باید با توجه به رفتار مور
د نظر آن واحد باشد. الهام گرفتن از توسعه نرم افزاری چابک برای «رفتار مورد نظر» در این مورد شامل الزاماتی است که توسط کسب و کار تعیین می شود — یعنی رفتار مورد نظر که ارزش کسب و کار را برای هر نهاد که واحد نرم افزاری را در دست ساخت دارد، به کار گرفته است. این مورد در طی فعالیت ت.ر.م تحت عنوان برون گرا بودن ت.ر.م یاد می شود. مشخصه های رفتاری. به دنبال این انتخاب اساسی، انتخاب دوم ساخته شده توسط BDD در ارتباط با چگونگی مشخص کردن نحوه «رفتار مورد نظر» می باشد. در این زمینه، BDD تصمیم به استفاده از قالب نیمه رسمی برای خصوصیات رفتاری می کند که از مشخصات داستان کاربری در حوزه تحلیل و طراحی شی گرا گرفته شده است. جنبه های سناریو این قالب ممکن است به عنوان اعمال منطق هوآر به مشخصه رفتاری واحدهای نرم افزاری با استفاده از زبان دامنه در نظر گرفته شود. ت.ر.م مشخص می کند که تحلیلگران کسب و کار و توسعه دهندگان باید در این زمینه همکاری داشته باشند و رفتارها را در قالب عبارت های داستان های کاربریی مشخص کنند، که هر کدام صریحاً در یک سند اختصاصی نوشته می شوند. هر داستان کاربر به نحوی باید از ساختار زیر پیروی کند: توسعه رفتار محور
هیچ الزام رسمی برای اینکه دقیقاً چگونه این داستان های کاربر باید نوشته شود ندارد، اما اصرار دارد که هر تیم استفاده کننده از آن یک فرمت ساده و استاندارد برای نوشتن داستان های کاربر که شامل عناصر ذکر شده در بالا است، طراحی کند. با این حال، در سال ۲۰۰۷، دن نورت یک قالب را برای فرمت متنی پیشنهاد کرد که در ابزارهای مختلف نرم افزار ت.ر. م دنبال شده است. مثال بسیار کوتاهی از این فرمت ممکن است مانند این باشد: داستان: مرجوعی کالا به عنوان یک صاحب فروشگاه به منظور پیگیری موجودی کالا من می خواهم کالاهای بازگشتی را به موجودی کالا، اضافه کنم. سناریو ۱: موارد مسترد باید به موجودی کالا افزوده شود داریم: یک مشتری قبلاً یک ژاکت سیاه از من خریداری کرده است و من سه ژاکت سیاه در انبار دارم. وقتی که او ژاکت سیاه را برای بازپرداخت بازمی گرداند. آنگاه من باید چهار ژاکت سیاه در انبار داشته باشم. سناریو ۲: موارد جایگزین باید به انبار بازگردانده شوند. داریم: مشتری قبلاً یک لباس آبی از من خریداری کرده است و من دو لباس آبی در انبار موجود دارم و من سه لباس سیاه در انبار موجود دارم. وقتی که او لباس آبی را برای جایگزینی با رنگ مشکی بازمی
گرداند آنگاه من باید سه لباس آبی در موجودی کالا داشته باشم. و دو لباس مشکی در موجودی کالا داشته باشم. سناریوها به صورت الزامی بدون اشاره به عناصر رابط کاربری (UI) که از طریق آن تعاملات صورت می گیرد، به صورت قانع کننده ای به زبان تجاری بیان می شوند، این نوع فرمت تحت عنوان زبان Gherkin یاد می شود؛ که دارای نحو مشابه مثال فوق می باشد، اما اصطلاح "Gherkin" به ابزارهای نرم افزار Cucumber و JBehave و Behat اختصاص دارد. خصوصیات به عنوان زبان فراگیر. توسعه رفتار محور مفهوم "زبان فراگیر" را از طراحی دامنه محور وام می گیرد. زبان فراگیر یک زبان نیمه رسمی است که توسط همه اعضای یک تیم توسعه نرم افزاری به اشتراک گذاشته شده است - هم توسعه دهندگان نرم افزار و هم پرسنل غیر فنی. زبان مورد نظر، به عنوان یک ابزار رایج برای بحث در رابطه با دامنه نرم افزار، توسط همه اعضای تیم مورد استفاده و توسعه قرار می گیرد. به این ترتیب، ت.ر. م وسیله ای برای ارتباط بین همه نقش های مختلف در یک پروژه نرم افزاری می شود. یک مخاطره متداول در توسعه نرم افزار شامل تفکیک ارتباطات بین توسعه دهندگان و ذینفعان کسب و کار است. ت.ر. م از مشخصات رفتار مورد نظ
ر به عنوان یک زبان عمومی برای اعضای تیم پروژه استفاده می کند. به همین علت است که ت.ر. م بر روی یک زبان نیمه رسمی برای خصوصیات رفتاری اصرار می ورزد: برخی از تشریفات برای داشتن یک زبان فراگیر الزامی هستند. علاوه بر این، داشتن چنین زبان فراگیری، یک مدل دامنه مشخصات را طوری ایجاد می کند که از رسمی بودن نتیجه شده باشند. این مدل همچنین اساس کاری ابزارهای نرم افزاری در دسترسی که از ت.ر. م پشتیبانی می کنند می باشد. مثال فوق یک داستان کاربر را برای یک سیستم نرم افزاری تحت توسعه ایجاد می کند. این داستان کاربر یک ذی نفع، یک تأثیر تجاری و یک ارزش تجاری را شناسایی می کند. همچنین چندین سناریو، هر کدام با پیش شرط، اجراکننده و نتیجه مورد انتظار را شرح می دهد. هر یک از این قسمت ها دقیقاً با بخش رسمی زبان شناخته می شود (بع نوان مثال ممکن است اصطلاح داریم (Given) ممکن است به عنوان یک کلمه کلیدی در نظر گرفته شود) و در نتیجه ممکن است به طریقی توسط یک ابزاری که قسمت های فرمال زبان فراگیر را درک می کند، مورد استفاده قرار گیرد. بیشتر برنامه های کاربردی ت.ر. م از DSLهای مبتنی بر متن و روش های مبتنی بر ویژگی استفاده می کنند. با این حا
ل، مدلسازی گرافیکی سناریوهای ادغام نیز در عمل به طور موفقیت آمیز برای مثال برای اهداف تست استفاده شده است. تخصصی قطعه سازی پشتیبانی. به نظر می رسد، مانند تمرین طراحی مبتنی بر تست، توسعه رفتار محور مبتنی بر استفاده از ابزار پشتیبانی تخصصی در یک پروژه است. به همان اندازه که ت.ر. م در بسیاری جهات یک نسخه خاص تر از TDD است، ابزار ت.ر. م مشابه آنچه برای TDD است می باشد، اما درخواست های بیشتری را نسبت به توسعه دهندگان ابزار TDD اولیه ایجاد می کند. قالب اصول. در اصل یک ابزار پشتیبانی ت.ر. م یک چارچوب آزمایشی برای نرم افزار است، کاملاً شبیه ابزارهایی که TDD را پشتیبانی می کنند. با این حال، در جایی که ابزارهای TDD در آنچه که برای تعیین تست مجاز است تمایل به فرمت کاملاً آزاد دارد، ابزار ت.ر. م با تعریف زبان عمومی که پیشتر بحث شده است، مرتبط است. همان طور که مورد بحث قرار گرفت، زبان فراگیر، تحلیلگران تجاری را قادر می سازد تا الزامات رفتاری را به نحوی که توسعه دهندگان آن را درک کنند، بنویسند. اصل ساخت ابزارهایی با پشتیبانی از ت.ر. م این است که اسناد نیازمندیها را مستقیماً به عنوان مجموعه ای از آزمون های قابل اجرا ایجاد ک
ند. چنانچه این مورد به دلایل مربوط به ابزار فنی که امکان اجرای مشخصات را فراهم می کند قابل دستیابی نباشد، باید سبک نوشتن الزامات رفتاری را تغییر داده یا ابزار را تغییر دهید. اجرای دقیق الزامات رفتاری در هر ابزار متفاوت است، اما عملکرد چابک با روند عمومی زیر مطابقت دارد: دن نورس تعدادی از چارچوب هایی را پشتیبانی می کند که از ت.ر. م پشتیبانی می کنند (از جمله JBehave و RBehave) عملیات آن بر اساس الگویی است که او برای ضبط داستان های کاربر پیشنهاد می کند. این ابزارها از توضیحات متنی برای موارد استفاده و چندین ابزار دیگر (مانند CBehave) استفاده می کنند. با این حال، این فرمت لازم نیست و چنان که ابزارهای دیگری وجود دارد که از فرمت های دیگر نیز استفاده می کنند. به عنوان مثال Fitnesse (که بر حول جدول تصمیم ساخته شده است) نیز برای تدوین ت.ر. م مورد استفاده قرار گرفته است. مثال برای ابزارها. نمونه های متعددی از ابزارهای نرم افزاری BDD که در پروژه ها امروزی، برای زبانها و سیستم های عمل مختلف مورد استفاده هستند وجود دارد. احتمالاً شناخته شده ترین آن ها JBehave است که توسط Dan North توسعه داده شده است. مثال زیر از این پروژه
گرفته شده است: پیاده سازی بازی زندگی را در نظر بگیرید. یک متخصص دامنه (یا تحلیلگر کسب و کار) ممکن است بخواهد مشخص کند که وقتی کسی تنظیمات پیکربندی اولیه خانه های بازی را تنظیم کند چه باید رخ دهد. برای انجام این کار، ممکن است بخواهید نمونه ای از تعدادی از اقداماتی که توسط فردی که خانه ها را سوییچ می کند مشخص کند. با رفتن به بخش روایت، او می تواند این کار را با نوشتن سناریو زیر به یک سند متن ساده (که نوعی سند ورودی است که JBehave قادر به خواندن آن است): داریم: یک بازی ۵ در ۵ وقتی که من وضعیت خانه (۳, ۲)را تغییر می دهم آنگاه جدول بازی باید وضعیت زیر را داشته باشند ... ..X.. وقتی که من وضعیت خانه (۳, ۱) را تغییر می دهم آنگاه جدول بازی باید وضعیت زیر را داشته باشند ... ..X.. ..X.. وقتی که من وضعیت خانه (۳, ۲)را تغییر می دهم آنگاه جدول بازی باید وضعیت زیر را داشته باشند ... ... ..X.. متن های با فونت پررنگ بخشی از ورودی نیست؛ بلکه در اینجا آمده است تا نشان دهد که کدام کلمات به عنوان زبان رسمی شناخته شده اند. JBehave کلمات داریم (Given) (به عنوان پیش شرطی که شروع یک سناریوی را مشخص می کند)، وقتی که (When) (به عنوان
یک راه انداز رویداد) و آنگاه (Then) (به عنوان یک نتیجه شرط که باید به عنوان نتیجه عمل که به دنبال ماژول تأیید می شود، شناسایی شود). بر این اساس JBehave قادر به خواندن فایل متنی حاوی سناریو و تجزیه آن به مقادیر (یک بند تنظیم و سپس سه رویداد با شرایط قابل تأیید) می باشد. سپس JBehave این مقررات را می گیرد و آن ها را به کدی که قادر به تنظیم یک آزمون و پاسخ به فراخوانندگان رویداد و تأیید نتیجه است ارسال می کند. این کد باید توسط تیم توسعه دهندگان پروژه نوشته شود (در زبان جاوا به دلیل اینکه پلت فرم JBehave بر اساس زبان جاوا می باشد). در این مورد، کد مورد نظر ممکن است مشابه کد زیر باشد:&lt;syntaxhighlight/&gt;کد برای هر نوع عبارتی در یک سناریو یک روش دارد. JBehaveJBehave مشخص می کند که کدام روش با کدام عبارت، از چه کاربردی از حاشیه نویسی استفاده کند و هر متد را در هنگام اجرا از طریق سناریو فراخوانی کند .انتظار می رود متن هر عبارت سناریو با قالب متن داده شده در کد برای آن بند مطابقت داشته باشد (برای مثال، انتظار می رود که در یک سناریو عبارت داریم (Given) با یک جمله از فرم "یک بازی X در Y" دنبال شود). JBehave از تطبیق
عبارات به قالب ها پشتیبانی می کند و دارای پشتیبانی داخلی برای درآوردن الفاظ از قالب و انتقال آن ها به عنوان پارامتر به متدها در کد آزمون می باشد. کد تست برای هر نوع بند در یک سناریو یک نوع پیاده سازی فراهم می کند که با کد مورد آزمایش تعامل می کند و بر اساس سناریو تست انجام می دهد. در این مورد: عملکرد اصلی این کد ایجاد پلی بین یک فایل متنی با یک داستان و کد مورد آزمایش است. توجه داشته باشید که کد آزمون دارای دسترسی به کد مورد آزمایش (در این مورد یک نمونه از codice_7) است و در طبیعت بسیار ساده است. کد آزمون باید ساده باشد، در غیر این صورت یک توسعه دهنده مجبور به نوشتن آزمون برای آزمایشهایش خواهد بود. در نهایت، برای اجرای آزمون، JBehave به برخی از برنامه های رابطی نیاز دارد که فایل های متنی را که حاوی سناریو هستند و وابستگی ها (مانند موارد بازیcodice_8)را به کد آزمون تزریق می کند، شناسایی کند .این کد رابط در اینجا نشان داده نمی شود، زیرا یک نیاز فنی JBehave است و مستقیماً به اصل تست ت.ر.م مربوط نمی شود. داستان در مقابل مشخصات. یک زیر شاخه جداگانه توسعه مبتنی بر رفتار به وسیلهٔ ابزارهایی است که از مشخصات به عنوان
زبان ورودی به جای داستان کاربر استفاده می کنند. یک نمونه از این سبک ابزار RSpec است که توسط دن نورس توسعه داده شده است. ابزارهای مشخصات از داستان های کاربر به عنوان یک فرمت ورودی برای سناریوهای آزمایش استفاده نمی کنند، بلکه از ویژگی های عملکردی برای واحدهای مورد آزمایش استفاده می کنند. این مشخصات اغلب دارای ماهیت فنی بیشتری نسبت به داستان های کاربر هستند و معمولاً برای ارتباط با پرسنل تجاری به اندازه داستان های کاربر، مناسب نیستند. یک نمونه از این مشخصه برای پشته می تواند به صورت زیر باشد: مشخصات: پشته وقتی که: یک پشته جدید ایجاد می شود. آنگاه: آن پشته خالی است. وقتی که: یک عنصر به پشته اضافه می شود آنگاه: این عنصر در بالای پشته قرار دارد وقتی که: یک پشته دارای N عنصر است. و عنصر E در بالای پشته قرار دارد آنگاه: a یک دستور pop عنصر E را بازمی گرداند و اندازه جدید پشته N-1 است چنین ویژگی ممکن است دقیقاً مشخص کند که رفتار مؤلفه مورد آزمایش چیست، اما برای یک کاربر تجاری چندان معنادار نیست. در نتیجه، تست مبتنی بر مشخصات در عمل ت.ر.م به عنوان مکمل تست مبتنی بر داستان دیده می شود و در سطح پایین تری عمل می کند. تست
مبنی بر مشخصات اغلب به عنوان یک جایگزین برای آزمایش واحد با فرمت دلخواه دیده می شود. ابزارهای تست مشخصات مانند RSpec و JDave از ابزارهایی مانند JBehave در طبیعت تا حدودی متفاوت هستند. از آنجایی که آن ها به عنوان جایگزینی برای ابزارهای تست پایهٔ واحد مانند JUnit, دیده می شوند، این ابزار تمایل دارد از جدایی داستان و کد تست چشم پوشی کند و ترجیح می دهد خصوصیات را مستقیماً در کد تست تعبیه کند. به عنوان مثال، یک آزمون RSpec برای hashtable می تواند به صورت زیر باشد: describe Hash do it "hashes the correct information in a key" do expect(hash[:hello]).to eq('world') end it 'includes key' do hash.keys.include?(:hello).should be true end end این مثال مشخصاتی را در زبان قابل خواندن که در کد اجرایی تعبیه شده است نشان می دهد.Iدر این مورد، انتخاب ابزار این است که با اضافه کردن متدهایی به نام codice_9 و codice_10 زبان مشخصه ها را به زبان کد تست رسمی تبدیل کند. همچنین مفهوم یک پیش شرط مشخصه تحت عنوان بخش codice_11 وجود دارد که پیش شرط هایی را که مشخصات بر اساس آن است، ایجاد می کند. Hash includes key hashes the correct infor
mation in a key
اِفلورنتین () با نام تجاری «Vaniqa» دارویی است که جهت درمان بیماری خواب و رشد نابجای مو در چهرهٔ بانوان بکار می رود. این دارو در مرحلهٔ دوم بیماری خواب که در اثر «تریپانوما بروسئی گامبینس» به وجود آمده باشد، کاربرد دارد و می توان آن را همراه با داروی نیفورتیموکس تجویز کرد. این دارو دو فرم تزریقی و کِرِم موضعی دارد. عارضهٔ جانبی کِرِم موضعی شامل راش پوستی، قرمزی و سوزش است. عارضه جانبی فرم تزریقی آن، احتمال بروز نارسایی مغز استخوان و تشنج است. هنوز بی خطر بودن مصرف آن در دوران حاملگی یا شیردهی مشخص نشده است. توصیه شده که مصرف این دارو تنها در بالغین و کودکان بالای ۱۲ سال باشد. افلورنتین یکی از داروهای ضروری سازمان جهانی بهداشت است که مجموعه ای از مؤثرترین و بی خطرترین داروهای ضروری برای سیستم بهداشت هستند. تا سال ۲۰۱۵ میلادی نوعِ ژنریک این دارو، در بازارهای آمریکا موجود نبود و فرم تزریقی آن تنها از طریق مرکز کنترل و پیشگیری بیماری ها قابل تهیه است. در دههٔ ۹۰ میلادی، هزینهٔ یک دورهٔ درمانی، ۲۱۰ دلار آمریکا بود. در نقاطی از جهان که در آن بیماری خواب شایع است، این دارو به صورت مجانی توسط سازمان جهانی بهداشت در ا
ختیار بیماران قرار می گیرد.
بلوچستان منطقه ای است که امروزه بخش هایی از سه کشور ایران، پاکستان و افغانستان را شامل می شود. بلوچستان همچنین ممکن است به یکی از موارد زیر اشاره داشته باشد:
جام ملت های آفریقا ۲۰۱۳ () بیست و نهمین دوره از رقابت های جام ملت های آفریقا بود که به میزبانی کشور آفریقای جنوبی برگزار شد. ۱۶ تیم در ۴ گروه ۴ تیمی به رقابت پرداختند. تیم ملی فوتبال نیجریه در این دوره از رقابت ها به مقام قهرمانی جام ملت های آفریقا رسید. کنفدراسیون فوتبال آفریقا تصمیم گرفت بر خلاف روال معمول که بازیها هر دو سال یکبار برگزار می شد این دوره را یک سال بعد از دوره قبل برگزار کند تا مشکل تداخل مسابقات جام جهانی فوتبال با مسابقات جام ملت های آفریقا برطرف شود. مطابق این تصمیم از این دوره به بعد مسابقات جام ملت های آفریقا در سال های فرد برگزار شد. انتخاب میزبان. کشورهای متقاضی: کشورهایی که میزبانی آن ها به تأیید اولیه نرسید : در تاریخ ۴ سپتامبر ۲۰۰۶ کنفدراسیون فوتبال آفریقا (CAF) پس از رد درخواست میزبانی نیجریه، از سایر کشورهای متقاضی درخواست کرد که برای میزبانی جام ملت های آفریقا باهم به توافق برسند. بدین ترتیب در رای گیری نشست کمیته اجرایی کنفدراسیون فوتبال آفریقا در قاهره مصر، موافقت شد که سه دوره بعدی جام ملت های آفریقا به ترتیب در سال ۲۰۱۰ به میزبانی کشور آنگولا، در سال ۲۰۱۲ به میزبانی مشترک کشو
رهای گینه استوایی و گابن و در سال ۲۰۱۴ به میزبانی کشور لیبی برگزار شود. میزبانی سال ۲۰۱۰ به دلیل حضور این کشور در مسابقات جام جهانی ۲۰۰۶ آلمان، زمینه سازی میزبانی برای کشورهای جدید، و نیز حرکت در مسیر صلح پس از جنگ داخلی آنگولا اعطا شد. کشور نیجریه به دلیل این که دو بار سابقه میزبانی داشت درخواست میزبانی اش رد شد و مقرر شد که به عنوان میزبان ذخیره جام ملت های ۲۰۱۰، ۲۰۱۲ و ۲۰۱۴ باشد تا در صورتی است که هر یک از کشورهای میزبان نتواند شرایط مورد نیاز CAF را برآورده سازد، جایگزین آن گردد. کنار گذاشته شدن لیبی. با توجه به جنگ داخلی لیبی در سال ۲۰۱۱، در سپتامبر ۲۰۱۱ در کمیته اجرایی CAF در قاهره مصر تصویب شد که میزبانی لیبی با آفریقای جنوبی جابه جا شود، به طوری که آفریقای جنوبی میزبان مسابقات جام ملت های آفریقا در سال ۲۰۱۳ شد و قرار شد که لیبی در سال ۲۰۱۷ میزبانی از مسابقات را برعهده بگیرد. بازیهای مقدماتی. در مجموع ۴۷ کشور از جمله آفریقای جنوبی وارد شدند، که به طور خودکار واجد شرایط است. لیبی پس از اینکه از حق میزبانی آن به دلیل جنگ داخلی لیبی کنار گذاشته شد، مجاز نبود که مجوز خود را حفظ کند. بسیاری از تیم ها در این
مسابقات به فینال بازگشتند. میزبان، آفریقای جنوبی پس از غیبت ۴ ساله بازگشت. اتیوپی اولین بار از سال ۱۹۸۲ ظاهر شد (یک غیبت ۳۱ ساله). تیم های دیگر که از سال ۲۰۱۲ نهایی بودند که در سال ۲۰۱۳ حضور داشتند، نیجریه، توگو، کنگو و الجزایر بودند. کیپ ورد نخستین مرحله خود را به پایان رساند. تیم هایی که برای این مسابقات از جام ملت های آفریقا در سال ۲۰۱۲ واجد شرایط نبودند هر دو میزبان، گابن و گینه استوایی، لیبی، سنگال، سودان، گینه و بوتسوانا بودند. سودان جنوبی مشروط به شرکت در مسابقات مقدماتی بود که از زمان عضویت خود در CAF تأیید شده بود. ورزشگاه ها. شهرهای میزبان. اتحادیه فوتبال آفریقای جنوبی از تمامی شهرهای میزبان جام جهانی ۲۰۱۰ دعوت کرد تا برای میزبانی اعلام آمادگی کنند و در تاریخ ۴ مه ۲۰۱۲ اسامی ورزشگاه های تایید شده اعلام شد. ورزشگاه اف ان بی به عنوان میزبان مسابقه افتتاحیه و نهایی معرفی شد. ورزشگاه های دیگری که برای مسابقات برگزیده شد، عبارت بودند از: ورزشگاه ام بومبل، ورزشگاه نلسون ماندلا بی، ورزشگاه رویال بافوکنگ و ورزشگاه موسی مابیدا. میانگین دمای روزانه شهرهای میزبان از ۲۵ درجه سانتی گراد (۷۷٫۰ درجه فارنهایت) تا
۳۰٫۳ درجه سانتیگراد (۸۶٫۵ درجه فارنهایت) است. سیدبندی. قرعه کشی مسابقات نهایی در ۲۴ اکتبر ۲۰۱۲ در دوربان انجام شد. موقعیت های A1 و C1 قبلا به میزبان (آفریقای جنوبی) و به (زامبیا) به عنوان قهرمان دوره قبل اختصاص داده شده بود. ۱۴ تیم دیگر واجد شرایط بر اساس عملکرد خود در سه جام ملت های آقریقا گذشته، یعنی نسخه های ۲۰۰۸، ۲۰۱۰ و ۲۰۱۲، رتبه بندی شدند. &lt;br&gt; امتیازات: &lt;br&gt; قهرمان ۷ امتیاز &lt;br&gt; تیم دوم جام ۵ امتیاز &lt;br&gt; حضور در نیمه نهایی ۳ امتیاز &lt;br&gt; حضور در یک چهارم نهایی ۲ امتیاز &lt;br&gt; حضور در دور گروهی ۱ امتیاز علاوه بر این، ضریب وزنی نقاط به هر یک از سه نسخه اخیر جام ملت های آفریقا به شرح زیر داده شد: &lt;br&gt; سال ۲۰۱۲: امتیازات باید در ۳ ضرب شود &lt;br&gt; سال ۲۰۱۰: امتیازات باید در ۲ ضرب شود &lt;br&gt; سال ۲۰۰۸: امتیازات باید توسط ۱ ضرب شود سپس تیم ها بر اساس رتبه بندی به ۴ گلدان تقسیم شدند. هر گروه شامل یک تیم از هر گلدان بود. مرحله گروهی. قوانین صعود به دور بعد. جایی که دو یا چند تیم واجد امتیاز مساوی در مرحله گروهی باشند رتبه بندی آن ها با معیارهای زیر تعیین می شود: گروه
A. &lt;onlyinclude&gt; &lt;/onlyinclude&gt; گروه B. &lt;onlyinclude&gt; &lt;/onlyinclude&gt; گروه C. &lt;onlyinclude&gt; &lt;/onlyinclude&gt; گروه D. &lt;onlyinclude&gt; &lt;/onlyinclude&gt; مرحله حذفی. در مراحل حذفی، اگر یک بازی در پایان بازی به طور طبیعی مساوی شد، زمان اضافی بازی (دو وقت ۱۵ دقیقه هر کدام) و در صورت لزوم، در ضربات پنالتی برنده تعیین خواهد شد، به جز بازی رده بندی (سوم و چهارمی) که هیچ وقت اضافی نباید انجام شود. نمودار. &lt;onlyinclude&gt; &lt;/onlyinclude&gt; جوایز. جوایز زیر در این دوره از مسابقات داده شد :
جام ملت های آفریقا ۲۰۱۵ () سی امین دوره از رقابت های جام ملت های آفریقا بود که به میزبانی کشور گینه استوایی برگزار شد. ۱۶ تیم در ۴ گروه ۴ تیمی به رقابت پرداختند. تیم ملی فوتبال ساحل عاج در این دوره از رقابت ها به مقام قهرمانی جام ملت های آفریقا رسید. انتخاب میزبان. کشورهای متقاضی: کنفدراسیون فوتبال آفریقا (CAF) قبل از ۳۰ سپتامبر ۲۰۱۰، آخرین مهلت درخواست میزبانی، ۳ پیشنهاد درخواست میزبانی جام ملت های آفریقا ۲۰۱۵ یا جام ملت های آفریقا ۲۰۱۷ از جمهوری دموکراتیک کنگو، مراکش و آفریقای جنوبی دریافت کرد. هر سه پیشنهاد در ابتدا در فهرست کوتاه قرار گرفتند. سپس اعضای CAF در ماه نوامبر و دسامبر ۲۰۱۰ از شرایط استادیوم ها، زیرساخت ها و علاقه های فوتبال هر سه کشور بازدید کردند. آنها اولین بار از کنگو بازدید کردند. اما اندکی پس از بازرسی، کنگو به CAF اعلام کرد که آنها پیشنهادها خود را برای رقابت های جام جهانی ۲۰۱۵ و ۲۰۱۷ حذف خواهند کرد. مراکش کشور بعدی بود که مورد بازرسی قرار گرفت و CAF در اوایل ماه نوامبر ۲۰۱۰ از کشور دیدن کرد. در نهایت آفریقای جنوبی در دسامبر ۲۰۱۰ بازرسی شد. در ۲۹ ژانویه ۲۰۱۱ و در جریان 2011 CAF Super Cup،