cyanic-selkie/wikianc huggingface dataset:
طاهر بن عبدالله
برگزیدن طاهر بن عبدالله به حکومت خراسان
اگرچه تمامی اطرافیان و درباریان مستقر در خراسان حکومت طاهر بن عبدالله را پذیرفتند و شعرا نیز به ذکر مرثیه برای عبدالله و وصف فرزندش پرداختند و حتی مردم آن سرزمین نیز به او گرایش داشتند، اما ظاهراً حکومت طاهر در خراسان با رضایت کامل خلیفه همراه نبود. واثق در آغاز به علت نارضایتی و واهمه از استمرار قدرت در میان فرزندان عبدالله بن طاهر در شرق خلافت، تمایلی به واگذاری حکومت خراسان به طاهر بن عبدالله نداشت. خلیفه قصد داشت تا حکومت خراسان را به اسحاق بن ابراهیم، که از شاخه‌های جانبی خاندان طاهری بود، واگذار نماید. به گفتهٔ شابشتی، با وصول خبر وفات عبدالله بن طاهر به واثق، محمد بن عبدالملک، وزیر خلیفه، وی را به برگزیدن اسحاق بن ابراهیم بن مصعب به حکومت خراسان توصیه کرد. احمد بن ابی داوود، قاضی‌القضات واثق، پس از آگاهی از این موضوع، به خلیفه یادآوری کرد که اسحاق در نزد خلیفه همچون گروگان خاندان طاهری در بغداد است و در صورت ارسال وی به خراسان به همراه سپاهیان و ثروت زیاد، قطعاً رفع خطر احتمالی او، مستلزم صرف هزینهٔ سنگینی است و در همین راستا بهتر است که با تسلیت فوت عبدالله به پسرش طاهر، حکومت خراسان به او واگذار شود زیرا با این اقدام میزان فرمانبرداری طاهر بن عبدالله نیز افزایش خواهد یافت.
اگرچه نمی‌توان مخالفت واثق با حکومت طاهر را امری مسلم دانست اما ظاهراً امر وراثت طاهریان در جریان حکومت بر سرزمین خراسان، موجب نارضایتی واثق همچون معتصم، خلیفهٔ پیشین شده‌بود که به رغم کینهٔ فراوان نسبت به عبدالله، قدرت برکناری وی را نیز از حکومت خراسان نداشت. وجود همین نارضایتی موجب شده‌بود که واثق درصدد نصب اسحاق بن ابراهیم به حکومت خراسان برآید.
دربارهٔ اسحاق بن ابراهیم ذکر این نکته لازم است؛ او جانشین عبدالله بن طاهر در بغداد بود و مناصب شرطگی، امارت فارس و سواد را نیز از جانب وی بر عهده داشت که واثق نیز به همین علت به واگذاری حکومت، به او تمایل داشت. آغاز خلافت واثق در سال ۲۲۷ ه./۸۴۲ م.، همزمان با اوج اقتدار و عظمت حکومت عبدالله بن طاهر در سرزمین خراسان بود و این وضعیت، موجبات نارضایتی وی را از قدرت عبدالله فراهم آورده‌بود. در همین راستا ممکن است که واثق به علت قدرت عبدالله در خراسان، از جانب وی احساس خطر کرده‌باشد. در مجموعه تمایلات و آمادگی‌های واثق برای اعمال تغییراتی در روند حکومت خراسان، باید به نقش برجستهٔ وزیر وی، محمد بن عبدالملک اشاره کرد که همان‌طور که پیش از این اشاره شد، بر طبق گفتهٔ شابشتی، پیشنهاد جانشینی اسحاق بن ابراهیم به واثق از جانب وزیرش صورت پذیرفت و میان آنان نیز روابط دوستانه برقرار بود.
به گفتهٔ‌‌‌ اکبری، روابط میان محمد بن عبدالملک و عبدالله بن طاهر خصمانه بود و مخالف‌هایی نسبت به محمد بن عبدالملک از جانب عبدالله صورت می‌گرفت. ابن طِقطَقی محمد بن عبدالملک را دارای صفات ناشایستی همچون تکبر، ظلم، خشونت و … ذکر کرده‌است که به همین علت، وی قادر به سازش با عبدالله که از صفات نیکو بهره داشت، نبود و همین سابقه را می‌توان در روند جانشینی طاهر و بدبین کردن خلیفه به وسیلهٔ وزیر، تأثیرگذار دانست. اگرچه به رغم تمام وقایع، در پایان واثق از نامزدی اسحاق بن ابراهیم برای حکومت خراسان چشم‌پوشی کرد و طاهر بن عبدالله را به همراه تمامی اختیاراتی که پیش از این در دستان عبدالله بود، به حکومت خراسان برگزید و عهد و لوا برایش ارسال کرد.
حکومت طاهر بن عبدالله بعدها نیز توسط خلفای دیگری همچون متوکل، منتصر و مستعین تأیید شد. او نیز در مقابل، خود را مولی‌امیرالمؤمنین می‌نامید و روابطی نیکو با خلفای مذکور داشت. او اسحاق بن ابراهیم را به همراه مناصبی که در بغداد داشت، به جانشینی خود برگزید.
آغاز انحطاط عباسیان در عصر متوکل
با شروع حکومت متوکل در سال ۲۳۲ ه.ق / ۸۴۷ میلادی، خلافت عباسیان در گردابی گرفتار شد که انحطاط تدریجی آن را در پی داشت. در این عصر خلافت اسلامی شاهد کاهش روزافزون قدرت خلیفه به رغم اقداماتی بود که در جهت توقف این روند انجام می‌شد. به تبع آن همزمان بر دامنهٔ رقابت میان مقامات حکومت و دیوان‌سالاران افزوده می‌شد که تلاش آنان برای مداخله در امور متعدد را به نمایش می‌گذاشت. همچنین متوکل سیاست دینی ضد معتزله‌ای را در پیش گرفت که دامن شیعیان را نیز گرفت و به اتفاقاتی چون تخریب آرامگاه حسین بن علی منجر شد. علاوه بر آن سران ترک در این عصر قدرت چشمگیری را تصاحب کرده بودند، به طوری که بر روند جانشینی تاثیر می‌گذاشتند و حتی به قتل متوکل اقدام کردند و نشانگر بروز هرج و مرج و بازیچه شدن مقام خلافت در دستان فرماندهان ترک‌تبار می‌باشد. اگرچه شاید بتوان نقطهٔ بروز این قدرت‌گیری شگرف ترکان را در پیروزی ترکان بر مقامات و بزرگان دولت عباسی در رقابت سیاسی بزرگی دانست که حاصل آن انتخاب متوکل به خلافت بود و موجب شد که زین پس تا مدت‌ها خلفای بعدی با نظر مستقیم ترکان انتخاب گردند. یکی از تاثیرات مخرب این واقعه بروز ناتوانی در ارکان خلافت و کاهش شدید قدرت تصمیم‌گیری خلفا بود که نظارت بر انتخاب و عزل ارکان دولت را از کف داده و تحت نفوذ ترکان درآمدند و نتیجهٔ آن عزل یا حبس عده‌ای از افراد لایق و مصادرهٔ اموالشان و جانشینی نالایقانی بود که با توسل به رشوه به مقام‌هایی مهم دست یافتند. همچنین نفوذ ترکان به حدی فزونی یافت که استبداد آنان در عمل را به دنبال داشت و متوکل را به فکر سرکوب قدرت آنان انداخت. او در این راه با قتل چندی از بزرگان ترک و محدود نمودن اختیاراتشان، عزل تعدادی دیگر و خروج از سامرا درصدد احیای قدرت خلیفه برآمد و سعی کرد تا با تکیه بر عرب ها خود را از سلطهٔ ترکان برهاند، اما به دلیل رنجش شدید اعراب از عباسیان به دلیل سرکوب امویان که سمبل اعراب محسوب می‌شدند، متوکل موفق به دست یافتن به مقصود خویشتن نشد. نقطهٔ اوج ضعف خلافت در این دوره و انحطاط عباسیان را در واقعهٔ قتل متوکل می‌توان شاهد بود که به رغم همهٔ تلاش‌های متوکل در راه مهار قدرت افسار‌گسیختهٔ ترکان، این امر محقق نشد و آنان علاوه بر این که خلیفه را وادار به بازگشت به سامرا نمودند، در طی توطئه‌ای نیز وی را از پا درآوردند و نشان دادند که تا چه حد قدرتشان بر خلافت اسلامی سایه انداخته است. قدرتی که تا چندین دهه سرنوشت حکومت اسلامی را تعیین می‌کرد.
منابع تاریخی اسلامی و به تبع آن تاریخ پژوهان مدرن متوکل را عامل ضعف عباسیان می دانند؛ زیرا هزینه های گزاف متوکل در توسعه قصرها و بناها را باعث هدر رفتن خزانه عباسیان برمی شمارند. با این حال به نوشته الحبری در تاریخ جدید اسلام کمبریج سیاست های متوکل منحصرا عامل این زوال نبوده است. وی انتقال پایتخت خلافت از بغداد به سامرا را از عوامل اصلی این انحطاط می داند. زیرا این شهر فاقد منابع حیاتی لازم برای توسعه زندگی شهری و تجاری بود و منابع خزانه باید صرف بقای شهر می شد. به هر حال متوکل، آخرین خلیفه مقتدر عباسی بود و با قتل وی، قدرت سیاسی به طور قاطع از پایتخت به استان ها منتقل شد، هرچند مرکزیت فرهنگی و اقتصادی در بغداد باقی ماند.
نافرمانی و شورش در سیستان و طبرستان
به گفته زرین کوب حکومت طاهر که مقارن با دوره ضعف خلفای عباسی بود، در نتیجه، برخی مدعیان قدرت در قلمرو وی قیام کردند و در سرزمین های تابع طاهریان هرج و مرج پدید آمد.
بنابر نظر اکبری، حکومت طاهر بن عبدالله دورانی از ضعف طاهریان را آغاز کرد چرا که وی معتقد است طاهر در ادارهٔ حکومت فردی توانا بود، اما موفقیت چندانی در بسط عدالت به دست نیاورد. وصیف، سپهسالار خلیفه در سال ۲۳۱ ه‍.ق / ۸۴۵ م برای همین ناآرامی‌های پیش آمده در جبال و فارس به این مناطق لشکرکشی کرد و موفق شد شورش‌ها را سرکوب کند و درست یک سال بعد، محمد بن ابراهیم، حاکم فارس شد. طبرستان و سیستان از جمله مناطقی بود که در دوران بعد باعث سقوط طاهریان شد، البته طبرستان در همان دوران طاهر هم اوضاع خوبی نداشت. طاهر پیش از به حکومت رسیدن، والی آنجا بود اما هنگامی که حکومت را به دست گرفت، برادرش، محمد بن عبدالله را به حکومت طبرستان برگزید تا اینکه در سال ۲۳۷ ه‍.ق / ۸۵۱ م اسحاق بن ابراهیم درگذشت، پس طاهر، محمد بن عبدالله را به عنوان رئیس شحنگان و نیابت عراق و فارس به بغداد فرستاد و سلیمان، برادر دیگرش را نیز به طبرستان فرستاد. در دوران سلیمان، نایب وی محمد بن اوس دست به آزار و اذیت مردم زد و باعث نارضایتی بسیار مردم طبرستان شد. سیستان نیز وضعیت خوبی نداشت؛ عبدالله بن طاهر نایب طاهریان در این شهر بود اما موفق نشد آنچنان که انتظار می‌رفت شهر را اداره کند. پس از مدتی ابراهیم بن حصین قوسی از جانب طاهر سیستان را به دست گرفت و با عیاران درگیر شد. احمد قولی که یکی از عیاران سیستان بود، دست به مبارزه علیه حکومت طاهریان زد؛ هرچند ابراهیم او را سرکوب کرد اما به خاطر تسامحی که در پیش گرفته‌بود باعث شد جرئت آن‌ها دو چندان شود و مطوعه هم وارد جدال شود، جدالی که تا مدت‌ها ادامه داشت و اجتناب‌ناپذیر بود.
روابط میان طاهر و متوکل
دو سال پس از شروع امارت طاهر بن عبدالله، واثق در سال ۲۳۲ هجری درگذشت و متوکل به خلافت رسید. روابط تنگاتنگی میان طاهر بن عبدالله و متوکل برقرار بود، چنان‌که متوکل پس از آغاز خلافت خویش، بار دیگر منشور حکومت خراسان را برای طاهر ارسال کرد. در مقابل، طاهر نیز فرامین خلیفه را در شرایط مختلف، به اجرا درمی‌آورد.
درگیری‌های خاندان طاهری در بغداد
در جریان رقابتی خانوادگی که میان اعضای خاندان طاهری در سال ۲۳۶ ه‍.ق/ ۸۴۶ م صورت پذیرفت، محمد بن ابراهیم، برادر اسحاق بن ابراهیم، که توسط متوکل در سال ۲۳۲ ه‍.ق/ ۸۴۶ م به حکومت فارس منصوب شده‌بود، به واسطهٔ اقدامات برادرزاده‌اش، محمد بن اسحاق، کشته شد و این امر به اجازهٔ خلیفهٔ وقت، متوکل صورت پذیرفت. وقوع این حادثه موجب شد تا متوکل مراتب تسلیت خویش را در طی نامه‌ای به طاهر بن عبدالله در خراسان اعلام نماید. پس از وفات اسحاق بن ابراهیم در سال ۲۳۵ ه‍. ق، فرزند او که محمد نام داشت، مدت کوتاهی مناصب پدر را عهده‌دار شد اما با وفات وی در سال بعد، طاهر بن عبدالله یکی از برادرانش به نام محمد را به جانشینی خویش در بغداد برگزید که محمد نیز در سال ۲۳۷ ه‍.ق/ ۸۵۱ عازم بغداد شد. اگرچه پیش از این واقعه نیز خاندان طاهری مستقر در بغداد، مطیع عموزادگان خود در خراسان بودند، اما با وقوع این رویداد و امارت محمد در بغداد، موقعیت خاندان طاهری خراسان از رونق و گسترش برخوردار شد و همچنین فرزندان عبدالله بن طاهر، در خراسان و بغداد، مهمترین مناصب و جایگاه‌ها را به خویش اختصاص دادند.
ماجرای علی بن جهم
در سال ۲۳۹ هجری، علی بن جهم از شعرا و ندیمان دربار متوکل بود که به موجب رفتار نکوهیده‌اش و شکایت درباریان از او، مورد خشم خلیفه قرار گرفت و به خراسان تبعید شد. طاهر نیز به دستور خلیفه، یک روز تمام وی را در شادیاخ بر بالای دار نگه داشت. علی بن جهم قصیده‌ای طولانی در این باب سرود. مدتی بعد طاهر به دستور متوکل، علی بن جهم را رها کرد و به او خلعت و لوازم سفر اهدا کرد.
قطع درخت سرو کاشمر
اما از دیگر مواردی که در آن اطاعت طاهر را از متوکل می‌توانیم مشاهده کنیم، واقعهٔ قطع درخت سرو کاشمر است. تاریخ بیهق اینگونه نقل کرده که زردشت دو درخت سرو را یکی در کاشمر و دیگری در قریه فریومد (سبزوار) به طالع سعد کاشته بود. در عصر متوکل، زمانی که سرو کاشمر را برای وی تشریح و توصیف کردند، دستور قطع درخت را برای طاهر صادر کرد تا بر اساس آن، درخت مذکور را قطع کنند و چوب‌های آن را برای خلیفه به سامره بفرستند تا از آن‌ها در جهت استفاده در ساختمان قصر جدیدش بهره گیرد. مردم و به ویژه زرتشتیان با این کار مخالفت ورزیدند و پیشنهاد پرداخت پنجاه هزار دینار زر نیشابور را برای جلوگیری از این کار به خلیفه دادند، اما طاهر که علاقه‌ای به نادیده گرفتن فرمان خلیفه نداشت به آنان گفت: «متوکل نه از آن خلفا و ملوک بود که فرمان وی را رد توان کرد». او پس از قطع درخت، چوب‌های حاصله را با شتر به سامرا فرستاد که این اقدام بالغ بر پانصد هزار درهم هزینه دربرداشت؛ اما متوکل پیش از رویت نتیجهٔ کار، توسط غلامان ترک خویش، به قتل رسیده‌بود. علاوه بر تاریخ بیهق، قدیمی‌ترین روایت در این باب در گشتاسب‌نامهٔ دقیقی بوده که دقیقاً توسط فردوسی روایت شده‌است. امکان دارد که به موجب این فرمان، عامل طاهر در قزوین نیز اقدام به قطع درخت کهنسالی کرده‌باشد که مورد احترام مردم بود.
مرگ طاهر بن عبدالله
طاهر بن عبدالله سرانجام در سال ۲۴۸ ه‍.ق / ۸۶۲ م در دوران خلافت مستعین فوت کرد. مرگ طاهر موجبات آرامش خاطر یاران خلیفه را فراهم آورد چرا که «اصحاب مستعین از هیچ کس چنان بیمناک نبودند که از امیر خراسان».
منش طاهر بن عبدالله
کنیهٔ طاهر ابوطیب بود. طاهر همچون پدرش فردی عادل بود. وی مردی عاقل بود و نسبت به آنچه دبیران حکومتی ثبت می‌کردند به شدت حساس بود. روایت است روزی که او را «رشید» خواندند عصبانی شد و گفته: «این نام بر کسی نهند، که خدای عزوجل او را سزاوار آن کرده‌باشد.» یعقوبی این چنین وضعیت حکومت طاهر بن عبدالله را توصیف می‌کند: «طاهر به طریقی درست بر خراسان حاکم راند و در زمان وی همه امور رو به راه بود.» طاهر بن عبدالله فردی علم دوست بود، او به شعرا و علما بسیار اهمیت می‌داد و سعی می‌کرد فرزندان خود را نیز با علوم زمانه آشنا سازد. در دوران وی شاعران بسیاری در دربار به تعریف و تمجید او می‌پرداختند و طاهر هم به آن‌ها سخت نمی‌گرفت. روزی شاعری نام مادر وی که «عزیزه» بوده را بیان می‌کند و طاهر خطاب به وی می‌گوید که نام مادرش را حتی کنیزانش هم نمی‌دانستند با این حال او را بخشید. منجمان هم در زمان طاهر در دربار وی حضور داشتند و در نیشابور به رصد ستارگان می‌پرداختند. طاهر نسبت به درخواست مردم بی‌توجه نبود؛ روزی مردم بخارا از وی درخواست کردند آن‌ها را در جهت ساخت دیوار شهر برای جلوگیری از حملهٔ راهزنان یاری کند و طاهر این چنین دستور داد:
سکه‌شناسی
پس از روی کار آمدن طاهریان، یحیی بن اسد سامانی کسی بود که تابعیت آنان را پذیرفت و به همین دلیل در پیرامون برخی از فلس‌های خود که در بنکث ضرب شده و بدون تاریخ می‌باشند، و نیز فلس‌هایی دیگر که در سال ۲۱۴ قمری ضرب کرده و فلس‌هایی که در سال ۲۳۳ قمری ضرب نموده، نام طاهر بن عبدالله را آورده‌است.
زنان در هند
وضعیت زنان در هند طی هزاره‌های اخیر تغییرات بزرگی کرده‌است. زنان هند در راستای دست یابی به حقوق برابر با بسیاری چالش‌ها روبرو بوده‌اند در هند مدرن، زنان توانسته‌اند به مناصب بالایی مانند ریاست جمهوری، نخست‌وزیری، سخنگوی مجلس سفلای پارلمان و رهبری اپوزیسیون دست پیدا کنند.
با این حال، زنان در هند همچنان با مشکلات متعددی از جمله تجاوز جنسی، اسید پاشی، بی حرمتی، اجبار به عروسی و فحشاء اجباری روبرو هستند. بنیاد تامسون رویترز هند را به عنوان بدترین کشور عضو جی بیست معرفی کرده‌است.
مرگ به‌خاطر جهیزیه
هر ساله تعداد زیادی از زنان هندی به‌دلیل ناکافی بودن جهیزیه به‌دست همسر یا بستگان او کشته‌می‌شوند. شیوهٔ متداول این قتل‌ها زنده سوزاندن عروس است که معمولاً به‌صورت خودکشی یا مرگ تصادفی جلوه داده می‌شود. این کشور تاکنون بیشترین میزان مرگ و میر مرتبط با جهیزیه را در جهان داشته‌است. بر اساس آمار دایره ملی ثبت جنایات هند، در سال ۲۰۱۲، ۸٫۲۳۳ مورد مرگ مربوط به جهیزیه در سراسر هند گزارش شده‌است. در سال ۲۰۰۲ صندوق کودکان سازمان ملل متحد اعلام کرده بود سالانه بیش از ۵۰۰۰ عروس به‌دلیل ناکافی بودن جهیزیه‌شان در هند کشته می‌شوند.
کوپلای اندلسی
در آغاز قرن بیستم در اسپانیا ظاهر شد و حتی در طول جنگ داخلی اسپانیا و دوره پس از جنگ نیز به قوت خود باقی ماند. این سبک موسیقی از سال 1950 حضور پررنگی در سینمای موزیکال و تئاتر اسپانیا داشته است. از دهه 1970، با رواج سایر سبک‌های موسیقی در اسپانیا، کاهش جزئی آغاز شد. با این حال، ریشه های قوی آن در هویت فرهنگی کشور و تعهد بسیاری از هنرمندان باعث شده است که هنوز هم این سبک موسیقی زنده باشد. از معرف ترین آهنگ های این سبک می توان به آهنگ هایی مانند María de la O ، ¡Ay pena، penita، pena ǃ ، Ojos Verdes یا Carmen de España اشاره کرد.
استفان تولمین
استفان تولمین (Stephen Toulmin؛ ۲۵ مارس ۱۹۲۲ – ۴ دسامبر ۲۰۰۹) فیلسوف، و استاد دانشگاه اهل بریتانیا بود. تولمین، که از لودویگ ویتگنشتاین تأثیر پذیرفته بود، فعالیت‌های خود را به تحلیل فلسفه اخلاق اختصاص داد. او در نوشته‌های خود تلاش داشت تا برهان‌هایی عملی توسعه دهد که بتوان از آنها در یافتن اصول اخلاقی بهره برد. نظریات او بعدها در زمینهٔ بلاغت برای تحلیل برهانها و در زمینهٔ علوم رایانه به کار گرفته شد.. تحقیقات او دربارهٔ اخلاق، منابع و مآخذی برای حوزه‌های روابط بین‌الملل، تاریخ و فلسفه، و علوم اجتماعی به‌شمار می‌روند.
وی همچنین برندهٔ جوایزی همچون کمک‌هزینه گوگنهایم شده‌است. تولمین در سال ۲۰۰۹ در سن ۸۷ سالگی درگذشت.
معهاد (روستا)
مهعاد  (در عربی:  المعهاد ) نام روستایی است در دهستان القفاعة از توابع استان تَعِز در کشور یمن در شبه جزیره عربستان.
جمعیت
جمعیت آن (۷۰ ) نفر (۸ خانوار) می‌باشد.
احمد بن محمد تغلبی
احمد بن محمد تَغلَبی شهرت‌یافته به ابنِ خَیّاط ( ۱۰۵۸م - ۱۱۲۳م) شاعر مدح‌سُرای دمشقی بود. پدرش خیّاط بود، از این به ابن خیاط مشهور شد. پس از آنکه سلجوقیان بر دمشق چیره شدند، به حماة رفت. کاتب امیر حلب شد، از این رو به ابن خیّاطِ کاتب آوازه گرفت. سپس به حلب رفت و با ابن حیوس ملاقات داشت. ابن خیاط در ۱۱ رمضان ۵۱۷ق در دمشق درگذشت.
مالاکس
مالاکْسْ (به لاتین: Malax) یک منطقهٔ مسکونی در فنلاند است که در اوستروبوتنیا واقع شده‌است.
بریشت
بریشت یک شهر در آلمان است که در مکلنبورگیشه زنپلاته واقع شده‌است. بریشت ۱۸۱ نفر جمعیت دارد.
شیخ آفتاب احمد
شیخ آفتاب احمد (شیخ آفتاب احمد؛ زادهٔ ) سیاست‌مدار، عضو مسلم لیگ، و از اوت ۲۰۱۷، وزیر پارلمانی معاملات پاکستان است.
رانسیلیو
رانسیلیو (Rancilio) شرکت لوازم خانگی ایتالیایی است، که در سال ۱۹۲۷ تأسیس شد.
رصدخانه اقلیم فضای ژرف
رصدخانه آب‌وهوای فضای ژرف (Deep Space Climate Observatory) که به اختصار DSCOVR نامیده می‌شود، ماهواره آب‌وهوایی اداره ملی اقیانوسی و جوی (NOAA) است که توسط شرکت اسپیس‌اکس با استفاده از حامل پرتاب فالکن ۹ در ۱۱ فوریه ۲۰۱۵ از پایکاه فضایی کیپ کاناورال به فضا پرتاب شد.
طرح اولیه این پروژه توسط ناسا توسعه داده شده و طرح آن در سال ۱۹۹۸ توسط ال گور معاون رئیس‌جمهور ایالات متحده آمریکا جهت اهداف دیدبانی زمین پیشنهاد شد.
آندرانیک هاکوبیان
آندرانیک هاکوبیان (Անդրանիկ Հակոբյան؛ زادهٔ ) بوکسور آماتور اهل ارمنستان است. او برندهٔ طلا و نقرهٔ مسابقات جهانی است و دو نوبت در مسابقهٔ المپیک حضور داشته‌است. هاکوبیان در دستهٔ میان‌وزن مسابقات قهرمانی بوکس آماتوری اروپا در سال ۲۰۰۹ در میلان به مدال نقره و در جام جهانی بوکس در سال ۲۰۰۸ در مسکو به مدال طلا دست یافت.
جان گیلرمین
جان گیلرمین (John Guillermin؛ زادهٔ ۱۱ نوامبر ۱۹۲۵ - درگذشته ۲۷ سپتامبر ۲۰۱۵) کارگردان و تهیه‌کننده اهل بریتانیا بود.
زندگی‌نامه
جان گیلرمین از پدر و مادری فرانسوی در لندن به دنیا آمد و پیش از پیوستن به نیروی هوایی سلطنتی بریتانیا به دانشگاه کمبریج رفت.
وی کارگردانی را در فرانسه و با ساخت فیلم‌های مستند آغاز کرد و در سال ۱۹۵۰ برای آموختن شیوه‌های فیلمسازی به هالیوود رفت. گیلرمین آسمانخراش جهنمی را که اثری کلاسیک در سبک اکشن-درام-فاجعه محسوب می‌شود را در ۱۹۷۴ کارگردانی نمود که در آن بازیگرانی همچون پل نیومن، استیو مک‌کوئین، ویلیام هولدن و فی داناوی ایفای نقش نمودند. این فیلم برنده سه جایزه اسکار شد. گیلرمین همچنین نسخه‌ای از فیلم کینگ کونگ را در سال ۱۹۷۶ کارگردانی نمود که در آن جف بریجز و جسیکا لانگ در آن بازی کردند. جان گیلرمین در سال ۱۹۷۸ اقتباسی از رمان مرگ در نیل اثر آگاتا کریستی را کارگردانی کرد. گیلرمین در سال ۱۹۸۰ جایزه فیلم بریتانیایی ایوینینگ استاندارد را برای فیلم مرگ بر روی نیل دریافت نمود. آخرین فیلمش را در سال ۱۹۸۶ با عنوان کینگ کنگ زندگی می‌کند کارگردانی بود که دنباله فیلم کینگ کنگ می‌باشد
جان گیلرمین، روز یکشنبه ۲۷ سپتامبر ۲۰۱۵ در سن ۸۹ سالگی در خانه‌اش در لس آنجلس درگذشت.
چرچ راک، نیومکزیکو
چرچ راک شهری در ایالت نیومکزیکو کشور ایالات متحده آمریکا است که جمعیت آن در سرشماری سال ۲۰۱۰ میلادی، ۱٬۱۲۸ نفر بوده‌است.
ماسیمیلیانو باربون
ماسیمیلیانو باربون (Massimiliano Barbone؛ زادهٔ July 12, 1991) بازیکن فوتبال اهل ایتالیا است.
از باشگاه‌هایی که در آن بازی کرده‌است می‌توان به باشگاه فوتبال دلفینو پسکارا اشاره کرد.
آنتوان بائومه
آنتوان بائومه (Antoine Baumé؛ زاده درگذشته ۱۷۲۸:۲:۲۶, ) یک شیمی‌دان اهل فرانسه بود.
عبدالله بن محمد بن سعود آل‌ثانی
عبدالله بن محمد بن سعود آل‌ثانی (Abdulla bin Mohammed bin Saud Al Thani؛ – ) سیاستمدار، دیپلمات و مدیر اجرایی اهل قطر بود.
زنان در قبرس
زنان در قبرس (Women in Cyprus) وضعیتی رو به پیشرفت است چرا که آن‌ها دسترسی گسترده به آموزش و پرورش و افزایش مشارکت در نیروی کار ملی را داشتند. زنان قبرس تا حد زیادی تحت تأثیر تغییرات پس از جنگ جهانی دوم قرار گرفتند. این زنان پیشرفت‌های بزرگی در جامعه خود کرده‌اند نه فقط در زمینه تحصیلات و اشتغال و کار، بلکه زنان بیشتری نیز در حال برگزاری ایجاد دفاتر و اجتماع سیاسی هستند.
جمعیت
بر اساس گزارش جهانی جمعیت، در سال ۲۰۱۴، جمعیت قبرس ۱۵۱۵٬۰۵۸ بود. زنان در قبرس ۴۸٫۹۴۴ درصد از کل جمعیت را تشکیل می‌دهند.
قاسم نقی‌زاده
سید قاسم نقی‌زاده موسوی (زاده ۱۳۴۹ در بابل ) قاضی و رئیس شعبه دوم دادگاه کیفری ۲ شهرستان گنبدکاووس است. او به دلیل ابتکارش در دادن حکم خرید کتاب، به جای تحمل حبس (زندان) برای برخی از مجرمان جرایم سبک، شهرت یافت.
با توجه به اینکه مجازات‌های جایگزین به جای حبس در دستور کار دادگستری قرار گرفته‌است، نقی‌زاده تلاش می‌کند مجازات‌های جایگزین را برای جرایمی که فاقد شاکی خصوصی هستند به ویژه بزهکاران نوجوان، افراد فاقد سابقه کیفری، جرایم سبک یا غیرعمدی یا با میزان خسارات وارده بسیار کم به شاکی، اعمال کند. به گفته او «در دادگاه کیفری ۲ شهرستان گنبد در هر نامه اعزام متهم به زندان اعلام شده که به وی ابلاغ کنند تا روز جلسه دادگاه ۵ جلد کتاب مطالعه و خلاصهٔ آن را به همراه یک برگه حدیث ارسال نماید.» «کتاب‌ها به نحوی انتخاب شده که برای همه زندانیان صرف نظر از میزان سواد و آگاهی و با هر میزان معلومات و برای هر سنی قابل استفاده باشد، کتاب‌هایی به زبان خیلی ساده تا کتاب‌های تخصصی که بار علمی بالایی در بر دارند از جمله این کتاب‌ها می‌باشد.» «حتی کتاب‌های قصه کودکان خردسال برای استفاده مادران آنان در زندان تهیه شده است.» این کتاب‌ها مهر «وقف نامه» می‌خورند.
قاسم نقی‌زاده در دفاع از مجازات‌های جایگزین حبس معتقد است «زندان اثرات مادی و روانی جبران ناپذیری بر مجرم و خانواده او می‌گذارد که با مجازات جایگزین حبس می‌توان آن را کاهش داد. فراهم کردن امکان پذیرفته شدن محکومین در جامعه و پیشگیری از رفتار ضد اجتماعی آنان، به حداقل رسیدن حس انتقام در فرد محکوم و کاستن از هزینه نگهداری زندانی شامل پوشاک، خوراک و حفاظت مهمترین مزایای مجازات‌های جایگزین حبس است.»
چارلز مونتاگ بیکول
زندگی‌نامه
پس از جنگ، بیکول به عنوان نماینده جمهوریخواه جمهوریخواه از کنتیکت به مجلس سنا رفت و از ۱۹۲۰ تا ۱۹۲۴ خدمت کرد. از سال ۱۹۲۱ تا ۱۹۲۳، او به عنوان رئیس کمیته دولتی مجلس نمایندگان کار کرد تا قوانین آموزشی ایالت کنتیکت را تجدید نظر و اصلاح کند.
قاسم نقی‌زاده
از دیگر اقدامات او می‌توان به نصب پوسترها و نقاشی‌های چشم‌انداز طبیعت بر دیوارهای زندان و نصب بنرهایی با مضامین دینی و اجتماعی اماکن مذهبی بر دیوارهای زندان، کلانتری‌ها و پاسگاه‌ها اشاره کرد.
چارلز مونتاگ بیکول
زندگی‌نامه
در سال ۱۹۳۲، بیکول به عنوان نماینده مجلس نمایندگان کنگره ایالات متحده انتخاب شد و یک دوره را از ۴ مارس ۱۹۳۳ تا ۳ ژانویه ۱۹۳۵ در کنگره ایالات متحده آمریکا خدمت کرد.
درگذشت
بیکول در ۱۹ اوت ۱۹۵۷ در نیوهیون، کنتیکت درگذشت و در آرامستان خیابان گروو در نیوهیون دفن شد.
پتار موسلیم
پتار موسلیم (Petar Muslim؛ زادهٔ ۲۶ مارس ۱۹۸۸) بازیکن واترپلو اهل کرواسی است.
وی در مسابقات کشوری و بین‌المللی در مجموع برندهٔ ۴ مدال طلا، ۲ مدال نقره، ۴ مدال برنز شده‌است.
اتحادیه اخائیه
اتحادیه اخائیه کنفدراسیونی از کشورها و شهرستان‌های یونانی بود. علت نام‌گذاری این اتحادیه به این نام، محل حکومت آن بود که در مکانی به نام اخائیه یا آخیا در مناطق شمالی و مرکزی پلوپونز بوده‌است. دوره حکومت اتحادیه اخائیه بین سال ۱۴۶ و ۲۸۰ پیش از میلاد بوده‌است. سپاه اتحادیه اخائیه متشکل از سربازانی سنتی از نوع هوپلیت بوده‌است.
مسکی شیبرو شیوان
مسکی شیبرو شیوان (מַסְקי שיברוּ-סיוון؛ متولد ۲۹ سپتامبر ۱۹۶۷) بازیگر و خواننده اسرائیلی است.
زندگی‌نامه
مسکی متولد اتیوپی است. در سال ۱۹۸۵، او زمانی که ۱۶ سال داشت، تنها و جدا از خانواده به اسرائیل آمد. ظاهراً او برای مطالعه علوم رایانه رفت اما در مدرسه بازیگری نیسان ناتو در تل آویو به تحصیل بازیگری پرداخت. بعداً خانواده اش هم به دنبال او به اسرائیل رفتند.
او در بسیاری از نمایش‌های تلویزیونی، فیلم‌ها و کنسرت‌ها شرکت داشت. بعضی از این‌ها مربوط به ریشه‌های اتیوپی او بود.
در سال ۱۹۹۹ او نقش Inbal را در یک قسمت از سریال تلویزیونی اسرائیلی Zinzana بازی کرد و همچنین در قسمتی از سریال Parparim (پروانه‌ها) که مخصوص کودکان بود هم ایفای نقش کرد.
شیبو سیروان در سال ۲۰۰۵ نقش مادرشلومو را در فیلم فرانسوی-بلژیکی-اسرائیلی-ایتالیایی "Va, vis et deviens" (عنوان انگلیسی: Go, Live, Become) را بازی کرد.
او همچنین در نقش ملکه شبه در Sipurim keyad Hamelekh، که برای کودکان برنامه سازی می‌کند Tuvia Sipurim keyad Hamelekh هم به بازی و خوانندگی پرداخت.
خوسه ماریا آرگداس
خوزه ماریا آرگداس ( ۱۸ ژانویه ۱۹۱۱-۲ دسامبر ۱۹۶۹م) رمان‌نویس، و شاعر پرویی بود. شناخت دقیقی بر فرهنگ سرخ‌پوستی آمریکای لاتین داشت.
جایزه گودل
جایزه گودل (Gödel Prize) نام یک جایزه سالانه است که به مقالات برگزیده و منتخب در زمینه علوم نظری کامپیوتر اهدا می‌شود. این جایزه به صورت مشترک توسط انجمن اروپایی علوم نظری رایانه و انجمن محسابات ماشینی اهدا می‌شود. این جایزه به افتخار کورت گودل نامگذاری گردیده است زیرا گودل اولین فردی بود که مسئله برابری پی و ان‌پی را مطرح کرد. او این مسئله را در نامه‌ای به جان فون نویمان مطرح کرده بود و از او پرسیده بود آیا مشکلات و مسائل مشخص ان‌پی کامل با زمان خطی یا درجه دوم قابل حل هستند یا نه.
ریزانی دو اچر
ریزانی دو اچر (Rizzani de Eccher) شرکت ساخت‌وساز ایتالیایی است، که در سال ۱۸۳۱ تأسیس شد.
صندوق ثروت ترکیه
صندوق ثروت ترکیه (Turkey Wealth Fund) صندوق ثروت ملی کشور ترکیه است، که در سال ۲۰۱۶ توسط دولت ترکیه تأسیس شد. مجموع دارایی‌های صندوق ثروت ترکیه بالغ بر ۳۳ میلیارد دلار برآورد می‌شود. این صندوق مالک شرکت‌های ترک تلکام، شرکت نفت ترکیه، شرکت پست ترکیه، ترکیش ایرلاینز، بانک زیارت، بورس استانبول، بوتاش، ترک‌ست و چایکور می‌باشد.
ژنرال نیروی هوایی
ژنرال نیروی هوایی یا ژنرال پنج ستاره دومین درجهٔ نظامی در نیروهای مسلح ایالات متحده بعد از ژنرال شش‌ستاره و دومین درجهٔ ممکن عملیاتی در نیروی هوایی ایالات متحده می‌باشد.
فرودگاه شهری گلزبرگ
فرودگاه شهری گلزبرگ یک فرودگاه همگانی بهره‌برداری هوایی با کد یاتا GBG است که یک باند فرود آسفالت دارد و طول باند آن ۱۷۶۶ متر است. این فرودگاه در کشور ایالات متحده آمریکا قرار دارد و در ارتفاع ۲۳۳ متری از سطح دریا واقع شده‌است.
برایتبرون
برایتبرون یک شهر در آلمان است که در هاسبرگه واقع شده‌است.
آنخلیکا واله
آنخلیکا واله (Angélica Vale؛ زادهٔ November 11, 1975) یک هنرپیشه، صداپیشه، خواننده، کمدین اهل مکزیک است. وی از سال ۱۹۷۵ میلادی تاکنون مشغول فعالیت بوده‌است.
نائه کارانفیل
نائه کارانفیل (Nae Caranfil؛ ؛ زادهٔ ) کارگردان فیلم، فیلم‌نامه‌نویس و بازیگر اهل رومانی است.
آنخلیکا واله
از فیلم‌ها یا مجموعه‌های تلویزیونی که وی در آن‌ها نقش داشته است می‌توان به بتی بی‌ریخته و زیباترین دختر زشت اشاره نمود.
نائه کارانفیل
گزیده فیلم‌شناسی
از فیلم‌هایی که وی در آن‌ها نقش داشته‌است، می‌توان به نیکوکاری، باقی سکوت است و نزدیک‌تر به ماه اشاره نمود.
آناتولی لوکیانوف
آناتولی لوکیانوف (Анатолий Иванович Лукьянов؛ May 7, 1930 – 1930:5:7, January 9, 2019) سیاست‌مدار اهل اتحاد جماهیر شوروی سوسیالیستی بود.
آناتولی لوکیانوف در ۹ ژانویه ۲۰۱۹، در سن ۸۸ سالگی درگذشت.
وی همچنین برندهٔ جوایزی همچون نشان انقلاب اکتبر و نشان پرچم سرخ کار شده‌است.
توسعه آزمون‌محور
توسعهٔ آزمون‌محور (به انگلیسی: Test-driven development) یک فرایند توسعهٔ نرم‌افزاری است که بر پایه تکرار یک سری دوره‌های خیلی کوتاه توسعه قرار دارد: ابتدا برنامه‌نویس یک مورد آزمایشی (در ابتدا دارای شکست) برای بهبود مطلوب یا ایجاد قابلیت جدید می‌نویسد، سپس کمترین مقدار تغییرات کدی را که باعث قبول شدن آزمایش می‌شود می‌نویسد، سپس کد جدید را با استانداردهای قابل قبول سازماندهی مجدد می‌کند. یک مهندس نرم‌افزار آمریکایی به نام کنت بک، که توسعه یا «بازکشف» این روش را به وی نسبت می‌دهند، در سال ۲۰۰۳ اظهار داشت که TDD طرح‌های ساده و الهام بخش اعتماد به نفس را تشویق می‌کند.
Test-driven development مربوط به مفاهیم آزمون-برای اولین بار (test-first programming concepts) برنامه‌نویسی و شدید برنامه‌نویسی (extreme programming) است که در سال ۱۹۹۹ مطرح شد اما اخیراً علاقه بیشتری را نسبت به خود ایجاد کرده‌است.
برنامه نویسان همین‌طور می‌توانند این مفهوم را برای بهبود و اشکال زدایی کد میراث تهیه شده با روش‌های قدیمی تر به کار گیرند.
در این روش، نرم‌افزار به‌صورت تدریجی توسعه می‌یابد. ابتدا تست‌ها و سناریوهای آزمونی تعریف می‌شوند که بر اساس نیازمندی‌ها و اهداف مشتریان تعیین می‌شوند. سپس، با نوشتن کدی ساده که تست‌ها را برآورده کند، پروسه توسعه آغاز می‌شود. در این مرحله، کد نوشته شده تنها کافیست تا تست‌ها با موفقیت اجرا شوند و همچنین ممکن است کد اولیه به صورت موقتی باشد. سپس، با ادغام قطعات کد جدید و با تضمین عبور تست‌ها، کد قابل اجرا و نهایی تولید می‌شود. این روند تکرار می‌شود تا نرم‌افزار به صورت کامل و با تمامی ویژگی‌ها و تست‌ها توسعه یابد.
استفاده از توسعه مبتنی بر آزمون برای بهبود کیفیت و قابلیت اطمینان نرم‌افزارها و افزایش سرعت توسعه بهره‌مندی‌های قابل توجهی دارد. مطالعات و پژوهش‌های انجام شده نشان می‌دهند که استفاده از توسعه مبتنی بر آزمون منجر به کاهش خطاها، اشکالات و باگ‌های نرم‌افزار، افزایش کیفیت و عملکرد آن، کاهش هزینه‌های ناشی از خطاها و تست‌های دستی و افزایش رضایت کاربران می‌شود.
یکی از مزیت‌های توسعه مبتنی بر آزمون، امکان شناسایی و رفع مشکلات نرم‌افزار در مراحل ابتدایی توسعه است. با تعریف تست‌ها و سناریوهای آزمون، احتمال وقوع خطاها و نقص‌ها در نرم‌افزار کاهش می‌یابد و توسعه‌دهندگان قادر به شناسایی و رفع این مشکلات در مراحل زودهنگام هستند. این امر باعث می‌شود که هزینه و زمان موردنیاز برای تصحیح خطاها در مراحل بعدی توسعه کاهش یابد و در نتیجه نرم‌افزار با کیفیت‌تر و پایدارتری تحویل داده شود.
با توجه به مزایای مذکور و مطالعات انجام شده در زمینه توسعه مبتنی بر آزمون، این روش به عنوان یک روش مؤثر در توسعه نرم‌افزار، با توجه به شواهد علمی و مزایای آن، بسیار مورد توجه قرار گرفته‌است.
چرخه توسعه آزمون محور
چرخه توسعه آزمون محور یک فرایند توسعه نرم‌افزار است که متکی بر تکرار یک چرخه توسعه بسیار کوتاه است که طی آن نیازمندی‌ها تبدیل به موارد آزمون بسیار خاص می‌شوند و سپس نرم‌افزار به قدری بهبود بخشیده می‌شود که فقط بتواند تست‌های مطرح شده را پاس کند. این روند مخالف نحوه توسعه سنتی نرم‌افزار است که اجازه می‌دهد تا بخش‌هایی به نرم‌افزار اضافه شود که هنوز تست‌های لازم را نگذرانده‌است و سپس آن بخش‌های جدید را تست می‌کند.
توسعه آزمون محور، بر مبنای نوشتن آزمون (Test) برای نرم‌افزار بر اساس نیازمندی‌ها (requirements) قبل از نوشتن برنامه شکل گرفته‌است. در این فرایند هدف توسعه دهنده معطوف به گذراندن این تست‌ها می‌شود. ابتدا چون برنامه خالی است، تمامی آزمون‌ها باید با عدم موفقیت رو به رو شوند، اما برنامه‌نویس گام به گام برای هر ویژگی (feature) این آزمون‌ها را پشت سر می‌گذارد که اگر در هر مرحله موفقیت‌آمیز نبود، بازمی‌گردد و کد را دیباگ می‌کند.
البته باید توجه داشت که در متدولوژی TDD علاوه بر آزمون‌های گام به گام نیازمند آزمون‌های موازی مستقل نیز هستیم.
چرخه کلی روش توسعه آزمون محور شامل گام‌هایی به ترتیب زیر است که بر اساس کتاب Test-Driven Development by Example نوشته شده‌است:
۱. یک تست جدید بنویس
در روش توسعه آزمون محور هر ویژگی جدید با افزودن یک تست شروع می‌شود. طبیعی است این تست باید طوری طراحی شود که تنها با افزوده شدن صحیح و کامل ویژگی جدید مطلوب پاس شود.
۲. تمام تست‌ها را اجرا کن و ببین آیا تست جدید پاس می‌شود یا خیر
در این مرحله قصد داریم مطمئن شویم تست جدیدی که افزودیم خطا بدهد، وگرنه با افزودن کد جدید امکان اینکه چک شود ویژگی جدید واقعاً به درستی افزوده شده‌است یا خیر وجود نخواهد داشت.
۳. کد را بنویس
در این گام تنها کد اضافه ای که نیاز هست تا تست جدید پاس شود را می‌نویسیم و به زیاده روی در توسعه نمی‌پردازیم.
۴. مجدداً تست‌ها را اجرا کن
این بار اگر تمام تست‌ها پاس شوند مطمئن می‌شویم که تمام ویژگی‌های قبلی به درستی کار می‌کنند و علاوه بر آن ویژگی جدید نیز به‌طور صحیح اضافه شده‌است.
۵. کد را Refactor کن
روشن است که کد کل برنامه باید هر چند وقت یک بار تمیز و مرتب شود تا از ایجاد کد کثیف اجتناب شود و امکان بهبود مناسب و سریع در آینده فراهم باشد. در این گام قصد داریم دقیقاً همین کار را انجام دهیم. در این گام به‌طور ویژه لازم است به ملاحظات توسعه همانند رعایت وراثت و خوانایی و امکان نگهداری مناسب کد و الگوهای طراحی برنامه توجه داشته باشیم.
۶. گام‌های ۱ الی ۵ را (برای هر ویژگی جدید که اضافه می‌کنی) تکرار کن
برای هر ویژگی جدید گام‌های فوق را تکرار می‌کنیم.
اصول کلیدی توسعه آزمون محور
TDD که در بین برنامه‌نویسان به دلیل توانایی خود در افزایش بهره‌وری، کیفیت نرم‌افزار و قابلیت نگهداری شهرت دارد، بر سه اصل اساسی بنا شده‌است. این اصول شامل مفاهیم Test-First، توسعه incremental و تست مکرر است.
روش Test-First: در TDD، تست‌ها نقشی محوری در سراسر فرایند توسعه دارند. آن‌ها به عنوان ناوبر عمل می‌کنند و کل سفر را هدایت می‌کنند. هر چرخه توسعه با ایجاد یک تست که عملکرد مورد نظر را تعریف می‌کند، آغاز می‌شود. TDD از چارچوب‌های تست خودکار استفاده می‌کند و آزمایش را در هر زمان معین تسهیل می‌کند. این امکان بازخورد دقیق و سریع در مورد رفتار برنامه را فراهم می‌کند.
توسعه incremental: با پذیرش توسعه incremental، پروژه‌ها به‌طور طبیعی به اجزای کوچک‌تر و قابل مدیریت‌تر تقسیم می‌شوند. این رویکرد تمرکز برنامه‌نویس را بر روی مشکل در دست، افزایش می‌دهد و در عین حال فرصت‌هایی را برای برنامه‌ریزی بهتر و توسعه برتر فراهم می‌کند.
تست مکرر: تست مکرر بازخورد ارزشمندی را در رابطه با نیازمندی‌های اجرا شده به برنامه‌نویسان ارائه می‌دهد. این به تشخیص زودهنگام عیوب کمک می‌کند و احتمال انتشار آن‌ها را کاهش می‌دهد. در نهایت، این مورد، منجر به افزایش سطح کیفیت و بهره‌وری می‌شود.
TDD با دریافت بازخورد سریع از طریق تست، به نوشتن کد تمیز برای پیاده‌سازی یک نیازمندی کمک می‌کند. برای توسعهٔ مبتنی بر آزمون دو قانون تعریف شده‌است:
۱- همیشه فقط در صورت شکست یک تست، برای آن کد بنویسید: این قانون بر اهمیت نوشتن یک تست شکست‌خورده قبل از پیاده‌سازی هر عملکرد جدید یا ایجاد تغییرات در کد موجود تأکید می‌کند. ایده این است که با ایجاد یک مورد آزمون (test case) شروع کنید که رفتار یا ویژگی مورد نظری که می‌خواهید پیاده‌سازی کنید را تعریف می‌کند. از آن‌جایی که شما هنوز هیچ کدی ننوشته‌اید، تست با شکست مواجه خواهد شد. این موضوع، تضمین می‌کند که شما یک هدف مشخص و دقیق برای پیاده‌سازی دارید.
با پیروی از این قانون، یک حلقه بازخورد ایجاد می‌کنید که در آن به‌طور مداوم تلاش می‌کنید تا با نوشتن حداقل مقدار کد لازم، تست شکست‌خورده را پاس کنید. پس از گذراندن تست، می‌توانید به مورد آزمون بعدی بروید یا کد خود را با اطمینان خاطر بازآرایی کنید و بدانید که هیچ مشکل جانبی ناخواسته‌ای برای خود ایجاد نکرده‌اید.
۲- همیشه تکراری را حذف کنید: این قانون توسعه‌دهندگان را تشویق می‌کند تا هر گونه افزونگی یا تکرار را در پایگاه کد خود حذف کنند. هنگامی که متوجه الگوهای تکراری یا منطق مشابه در تست‌ها یا کد تولیدی خود می‌شوید، استخراج و انتزاع آن‌ها به اجزا یا توابع reusable، مهم است.
تکرار در کد می‌تواند منجر به مشکلات متعددی شود، مانند افزایش تلاش برای حفاظت و نگهداری، احتمال بیش‌تر وجود خطاها و کاهش خوانایی کد. با حذف موارد تکراری، طراحی و ساختار کلی پایگاه کد خود را بهبود می‌بخشید و آن را قابل نگهداری، خواناتر و مستعد به خطای کم‌تری می‌کنید. اعمال این قانون نه تنها به حذف تکرار در یک تست یا فایل کد، بلکه به شناسایی الگوهای رایج در چندین تست یا ماژول نیز گسترش می‌یابد.
با توجه به این دو قانون، توسعهٔ مبتنی بر آزمون را می‌توان به عنوان یک مدل توسعهٔ iterative تعریف کرد که در آن برنامه‌نویس موارد آزمون را قبل از نوشتن کد با استفاده از نیازمندی‌ها استخراج می‌کند. سپس کدی برای افزایش عملکردی کوچک نوشته می‌شود تا در تست پاس شود و در صورت شکست تست، کد می‌تواند به‌طور مکرر برای افزایش کیفیت و طراحی مجدداً تغییر داده شود.
مزایای توسعه آزمون محور
یک مطالعه در سال ۲۰۰۵ به این نتیجه رسید که استفاده از روش توسعه آزمون محور به معنی نوشتن تعداد بیشتری تست هست و برنامه‌نویسانی که تعداد بیشتری تست می‌نویسند (برخلاف تصور عموم) بازدهی بیشتری دارند. همین‌طور برنامه‌نویسانی که از روش توسعه آزمون محور بهره می‌بردند گزارش کردند که به تعداد دفعات کمتری نیاز به استفاده از Debugger در کار خود داشتند، که این امر به نوبه خود موجب بهبود و افزایش بهره‌وری آنها می‌شود. چنین کاهشی در تعداد دفعات نیاز به استفاده از Debugger طبیعی به نظر می‌رسد، چرا که هر گام از توسعه و هر ویژگی جدیدی که به برنامه افزوده می‌شود خود همراه با تست در محل می‌باشد و تا زمانی که تست مربوطه و تمام تست‌های پیشین برنامه پاس نشوند به مرحله بعد نمی‌رویم. همین‌طور گزارش شده‌است که در روش توسعه آزمون محور هرگاه به خطایی برخورد کنیم معمولاً بازگشت به آخرین نسخه بدون خطا و شروع مجدد کار بهینه تر از استفاده از Debugger است که این امر عملاً نیاز به دیباگ کردن کد و هزینه‌های مالی و زمانی نگهداری و تعمیر کد را کاهش می‌دهد.
از ویژگی‌ها و مزیت‌های دیگر این متدولوژی می‌توان موارد زیر را نام برد:
۱. بررسی کامل‌تر در ابتدا
این فرایند باعث می‌شود قبل از نوشتن برنامه، به جنبه‌های مختلف نیازمندی‌ها فکر کنیم و مواردی که روش‌های موجود می‌توانند شکست بخورند را بررسی کرده و در داخل آزمون‌ها در نظر بگیریم.
۲. متمرکز کردن اهداف
برنامه‌نویس هدف خود را با داشتن آزمون‌ها به روشنی می‌داند و می‌توانند صرفاً با تمرکز بر روی همین آزمون‌ها، از یک هدف و نیازمندی مبهم خود را دور کند.
۳. کاهش هزینه‌ها در نهایت
ممکن است TDD در ابتدا پرهزینه به نظر بیاید، اما به دلیل این که فرایند آزمون مرحله به مرحله و برای بخش‌های مختلف برنامه و بر اساس نیازمندی‌های مورد نیاز است، احتمال وارد شدن هزینه سنگینی که به خاطر عدم تطابق برنامه با نیازها پرداخت خواهد شد کاهش میابد
۴. توسعه گام به گام
در بسیاری از موارد پیش آماده که برنامه را کامل نوشتیم و بعد به آزمون آن پرداختیم و به اشکالی برخوردیم، ولی چون از سر منشأ مشکلات به صورت دقیق آگاه نبودیم، نتوانستیم آن‌ها را رفع کنیم. توسعه آزمون محور این مسئله را نیز برای ما برطرف می‌کند.
۵. مستندسازی
اگر از عملکرد تابعی در برنامه اطمینان نداشته باشیم، می‌توانیم با بررسی آزمون مربوط به آن تابع و پاسخ مد نظر، شهودی از رفتار مورد انتظار آن تابع داشته باشیم.
۶. کدهای مرتب‌تر
با توجه به این که از رفتار تابع‌ها به صورت مجزا می‌توان اطمینان یافت، می‌توان refactoring را به صورت آنی‌تری انجام داد، همچنین سطح‌های دسترسی توابع (خصوصی و عمومی) را پس از اطمینان از صحت درستی به صورت درجا مشخص کنیم و مجبور نشویم برای تست یک تابع در توابع دیگر این سطح دسترسی‌ها را تغییر دهیم. استفاده از TDD منجر به نوشتن کدی می‌شود که تضمین می‌کند که هر بخش از کد، انجام وظایف خود را با دقت و صحت بالا انجام می‌دهد. این روش کمک شایانی می‌کند تا با اعتماد بیشتر به کدی که نوشته‌شده‌است، بتوانید آن را بهبود دهید. مخصوصاً از آن‌جا که شما در ابتدا کدی می‌نویسید که تست را پاس کند و سپس آن را refactor می‌کنید، مطمئن خواهید بود که کد شما شامل قسمت‌هایی که اضافه باشند و نیاز نشوند، نمی‌باشد و همچنین کد شما بهینه و مرتب و منطبق بر اصول clean code می‌باشد.
۷. کاهش هزینهٔ زمانی رفع مشکلات کد و دیباگ کردن آسان‌تر
با استفاده از TDD از آن‌جا که از مراحل ابتدایی تست‌ها نوشته می‌شوند، خطاها در مراحل بسیار زودتری شناخته می‌شوند و در مراحل زودتری معمولاً حل می‌شوند. این کار باعث می‌شود که نیاز به صرف زمان و هزینه برای رفع خطاهای بزرگ در مراحل بعدی کاهش می‌یابد. این به معنی صرفه‌جویی در زمان و منابع می‌باشد و سرعت توسعهٔ محصول نیز در این حالات نسبت به حالت عادی که زمان زیادی را برای دیباگ کردن صرف می‌کنیم به‌طور قابل توجهی بیشتر می‌شود.
۸. Test Coverage بالا و تضمین بیشتر از نرم‌افزار
با استفاده از TDD از آن‌جا که برای هر فیچری شما تست دارید، پس درصد بخشی از کد که به وسیلهٔ تست‌ها پوشش داده می‌شوند و تست می‌شوند بیشتر از سایر متودولوژی‌ها می‌باشد. همچنین از آن‌جا که برنامهٔ ما با unit testهای مختلف یا به‌طور کلی آزمون‌های مختلفی سنجیده می‌شود، می‌توانیم اطمینان خوبی از عملکرد آن داشته باشیم.
۱. ناتوانی در استفادهٔ عملی
در شرایط پذیرش و استفاده در صنعت، موانع فنی زیادی در هنگام پیاده‌سازی وجود دارد علاوه بر این که درک کامل این که چگونه باید آن را به کار گرفت، مشکل است و برداشت‌های متفاوتی از آن میان افراد مختلف وجود دارد؛ بنابراین، استفاده عملی از آن بسیار کم است که می‌توان آن را به عنوان یکی از معایب TDD دید. طبق بررسی‌ها تنها ۱۲ درصد از TDD به روش صحیح استفاده می‌کنند. احتمالاً با دستورعمل‌هایی که نحوهٔ درست پیاده‌سازی را پیشنهاد می‌دهند و افزایش دانش صنعت، بتوان این مورد را کمی بهبود بخشید.
۲. سرعت توسعه
TDD ممکن است باعث کاهش سرعت توسعهٔ کد شود. طراحی و نوشتن تست‌ها به تنهایی زمان‌بر است و ممکن است در ابتدا توسعهٔ کد و پیشروی را به‌طور قابل توجهی کندتر کند. علاوه بر این، این روش نیازمند تجربه و آموزش زیادی می‌باشد تا بهره‌وری بالایی از آن به‌دست آید. به همین دلیل، توسعه‌دهندگان جدید ممکن است برای استفاده از TDD نیاز به یادگیری و تسلط بیشتری داشته باشند.
۳. پیچیدگی بیشتر در فرایند توسعه و افزایش هزینه در برخی موارد
یکی دیگر از معایب TDD، ایجاد پیچیدگی در فرایند توسعه است. این روش نیازمند توجه و هماهنگی بیشتری در نوشتن تست‌ها، پیاده‌سازی کدها و اجرای تست‌ها است. همچنین، برای توسعه‌دهندگانی که به سیستم وارد می‌شوند، ممکن است برای درک کامل فرایند نیاز به زمان و تلاش و توجه بیشتری داشته باشند. این می‌تواند باعث کاهش کارایی و افزایش هزینه توسعه شود.
مقایسهٔ توسعهٔ مبتنی بر آزمون با دیگر متدولوژی‌ها
در این بخش، توسعه مبتنی بر آزمون را با روش‌های سنتی مانند توسعه مبتنی بر نیازمندی‌ها (Requirement-driven Development) و توسعه مبتنی بر مستندات (Documentation-driven Development) مقایسه می‌کنیم.
در توسعه مبتنی بر نیازمندی‌ها، نرم‌افزار بر اساس نیازمندی‌های کاربران و مشتری‌ها فنی توسعه می‌یابد. در این روش، ابتدا نیازمندی‌ها تعریف می‌شوند و سپس کد نوشته می‌شود تا نیازمندی‌ها را برآورده کند. تست‌ها و آزمون‌ها نیز پس از نوشتن کد، اجرا می‌شوند. این رویکرد ممکن است باعث ایجاد تست‌های ناکارآمد و کاهش کیفیت نرم‌افزار شود. در مقابل، توسعه مبتنی بر آزمون با تعریف تست‌ها در مرحله ابتدایی توسعه، از کاهش خطاها و بهبود کیفیت و قابلیت اطمینان نرم‌افزار بهره می‌برد.
در توسعه مبتنی بر مستندات، نرم‌افزار بر اساس مستندات و مشخصات فنی توسعه می‌یابد. در این روش، مستندات تهیه می‌شوند و بر اساس آن‌ها نرم‌افزار پیاده‌سازی می‌شود. تست‌ها و آزمون‌ها نیز بعد از نوشتن کد، اجرا می‌شوند. اما ممکن است در این رویکرد، تست‌ها برای بررسی جوانب‌های مختلف نرم‌افزار کافی نباشند و خطاهای مختلفی در فرایند توسعه رخ دهد. در مقابل، توسعه مبتنی بر آزمون با تعریف تست‌ها و سناریوهای آزمون کاملتر، تمام جوانب و قابلیت‌های نرم‌افزار را بررسی کرده و از کیفیت و عملکرد صحیح نرم‌افزار اطمینان حاصل می‌کند.
مطالعات نشان داده‌اند که استفاده از توسعه مبتنی بر آزمون منجر به کاهش خطاها، اشکالات و باگ‌های نرم‌افزار، افزایش کیفیت و عملکرد آن، کاهش هزینه‌های ناشی از خطاها و تست‌های دستی و افزایش رضایت کاربران می‌شود. در واقع، توسعه مبتنی بر آزمون با استفاده از رویکرد طراحی آزمون اول و پیاده‌سازی کد بر اساس آزمون‌ها، موجب تضمین عملکرد صحیح و قابل اعتماد نرم‌افزار و کاهش خطاها می‌شود.
با توجه به مزایای مذکور و مطالعات انجام شده در زمینه توسعه مبتنی بر آزمون، این روش به عنوان یک روش مؤثر در توسعه نرم‌افزار، با روش‌های سنتی مانند توسعه مبتنی بر نیازمندی‌ها و مستندات قابل مقایسه است و بهبود قابل توجهی در کیفیت و عملکرد نرم‌افزارها را به همراه دارد.
فریم‌ورک‌های توسعهٔ مبتنی بر آزمون
csUnit: فریم‌ورک csUnit یک ابزار رایگان و متن‌باز برای تست پروژه‌های NET. است و طوری طراحی شده‌است تا برای تمام زبان‌های .NET مانند C# و C++ کار کند. از دیگر فریم‌ورک‌های محبوب توسعهٔ مبتنی بر آزمون برای زبان‌های NET. می‌توان به NUnit اشاره کرد.
JUnit: یک ابزار آزمون واحد برای زبان برنامه‌نویسی جاوا است. JUnit بخش مهمی از توسعهٔ مبتنی بر آزمون است و از خانواده فریم‌ورک‌های آزمون واحد به اسم xUnit می‌باشد.
TestNG: یک فریم‌ورک محبوب تست برای زبان برنامه‌نویسی جاوا است که به کاربران اجازهٔ اجرای آزمون‌های خودکار برای اپلیکیشن‌های وب را می‌دهد. این فریمورک متن‌باز است و قابلیت‌های بیش‌تری نسبت به JUnit دارد که باعث افزایش محبوبیت آن در برنامه‌نویسان زبان جاوا شده‌است. هم‌چنین می‌توان با استفاده از این فریم‌ورک به همراه Selenium که یک ابزار برای مرور خودکار صفحات وب است، تست‌های خودکار قدرتمندی برای اپلیکیشن‌های وب ایجاد کرد.
Rspec: یک فریم‌ورک انجام آزمون برای زبان برنامه‌نویسی ruby است.
کارهای آزمون محور
روش آزمون محور در خارج از حیطه توسعه نرم‌افزار نیز به کار گرفته شده‌است. این روش تحت عنوان کار آزمون محور در تیم‌های تولیدی و خدماتی مورد استفاده قرار گرفته‌است. در کار آزمون محور همانند توسعه نرم‌افزار آزمون محور، تیم‌ها تعداد آزمون کنترل کیفیت برای هر جنبه از موضوع کار طراحی می‌کنند و سپس به ارزیابی آن و طراحی جهت ارضای آن می‌پردازند تا موفق شوند آن را پاس کنند.
شش گام ذکر شده در توسعه نرم‌افزار آزمون محور با تغییراتی جزئی به شکل زیر برای کار آزمون محور نیز به کار گرفته می‌شوند:
روش‌های برتر در توسعهٔ مبتنی بر آزمون
در این قسمت تعدادی از روش‌های برتر (best practices) توسعهٔ مبتنی بر آزمون را بررسی می‌کنیم:
فهم واضح نیازمندی‌ها هنگام شروع: برای شروع، فهم دقیق و واضحی از نیازمندی‌های ویژگی‌ای که قصد توسعهٔ آن را دارید به دست آورید. این کار به شما کمک می‌کند تا تست‌های متمرکز و مرتبط بنویسید.
نوشتن تست‌های ریز: هر تست باید روی یک رفتار یا کارایی مشخص تمرکز کند. تست‌های خود را کوتاه و متمرکز و تنها مربوط به یک جنبه از کد بنویسید. این کار خوانایی و نگهداری تست‌ها را راحت‌تر می‌کند.
برای حالت‌های خاص تست بنویسید: برای حالت‌های غیر معمول که می‌تواند شامل مرز بین دو سناریوی مختلف یا ورودی‌های خاص باشد، تست بنویسید. در این حالت‌ها پتانسیل وقوع خطا وجود دارد و می‌تواند منجر به شکست شود.
به‌طور مرتب بازآرایی کنید: بعد از اینکه یک تست با موفقیت پاس می‌شود، مقداری زمان برای بازآرایی و بازسازی کد و بهبود طراحی آن، بدون اینکه رفتار آن تغییر کند بگذارید. این کار به تمیز نگه داشتن و داشتن یک پروژه قابل نگهداری کمک می‌کند.
روند اجرای تست‌ها را سریع نگه دارید: اجرای تست‌های شما باید از سرعت بالایی برخوردار باشد تا بتوانید سلامت کد خود را به سرعت بررسی کنید. سرعت بالای اجرای تست‌ها اجازه می‌دهد تا سرعت توسعهٔ بیشتری داشته باشید و مشکلات را سریع‌تر متوجه شوید.
خودکارسازی تست‌ها: از فریم‌ورک‌ها و ابزارهای خودکارسازی تست‌ها استفاده کنید تا تست‌های خود را بتوانید به صورت خودکار اجرا کنید. این کار به شما اجازه می‌دهد تا تست‌های خود را بارها و بارها به راحتی اجرا کنید و آن‌ها را با جریان کاری خود ادغام کنید و مطمئن شوید که تست‌های مطمئن و قابل اطمینانی دارید.
به صورت پیوسته تست‌های خود را اجرا کنید: تست‌های خود را با محیط توسعه ادغام کنید و خطوط continuous integration یا CI بسازید تا به صورت خودکار، هر زمان که کد تغییر می‌کند، تست‌ها را اجرا کند و نتیجه را به شما اطلاع دهد. این کار به شما کمک می‌کند که در صورت فراموشی اجرای تست‌ها، در صورتی که تست‌ها پاس نمی‌شوند، کد شما وارد مرحلهٔ تحویل به مشتری نشود و تست‌ها به صورت پیوسته اجرا شوند.
تست‌هایی که شکست می‌خورند باید شما را به توسعه هدایت کنند: وقتی یک تست خطا می‌دهد، آن تست باید به شما راهنمایی کند که نیاز است کدام بخش از کد را بررسی کنید و روی آن کار کنید. باید بتوانید آن خطا را تحلیل کنید، دلیل آن را شناسایی کنید و کدی که مشکل را به وجود آورده‌است را درست کنید. شکست تست‌ها یک بازخورد ارزشمند برای بالا بردن کیفیت کد است.
نمونه‌های استفاده از توسعهٔ مبتنی بر آزمون در جهان واقعی
در حالی که درک مفاهیم و اصول TDD بسیار مهم است، مشاهدهٔ کاربرد عملی آن در سناریوهای دنیای واقعی، بینش ارزشمندی را در مورد مزایا و اثربخشی آن ارائه می‌دهد. در این بخش، مجموعه‌ای از نمونه‌های واقعی را که در آن TDD با موفقیت به کار گرفته شده‌است، بررسی می‌کنیم و نشان می‌دهیم که چگونه این رویکرد فرایند توسعه نرم‌افزار را متحول کرده‌است.
مبدل ارز
از توسعه تست محور می‌توان برای ساخت یک مبدل ارز استفاده کرد. این فرایند با نوشتن یک تست شکست‌خورده شروع می‌شود که رفتار مورد نظر مانند تبدیل دلار به یورو را تعریف می‌کند. اجرای تست در ابتدا شکست را تأیید می‌کند و اطمینان حاصل می‌کند که آزمایش به‌طور دقیق عملکرد مورد نظر را هدف قرار می‌دهد. در مرحلهٔ بعد، حداقل کد برای گذراندن آزمون پیاده‌سازی می‌شود و پس از آن مجدداً آزمون برای اطمینان از موفقیت آن اجرا می‌شود. بازآرایی مداوم امکان بهبود کد را بدون تغییر رفتار فراهم می‌کند. افزودن مکرر موارد آزمایشی بیش‌تر، اعتبارسنجی کامل عملکرد تبدیل ارز را ممکن می‌سازد و در نتیجه یک سیستم قابل اعتماد و دقیق ایجاد می‌کند.
بازی بولینگ
استفاده از TDD برای ایجاد یک سیستم امتیازدهی برای یک بازی بولینگ، اطمینان و دقت را تضمین می‌کند. توسعه‌دهندگان با شروع از تست‌های شکست‌خورده، منطق مورد نیاز برای گذراندن تست‌ها را به صورت تدریجی پیاده‌سازی می‌کنند. ماهیت تکرارشوندهٔ TDD امکان بازخورد و بهبود مستمر را فراهم کرده و مکانیزم امتیازدهی قوی را تضمین می‌کند. اصلاح مجدد کد باعث حفظ وضوح و سادگی و رعایت اصول کد تمیز می‌شود. با پیروی از این رویکرد، توسعه‌دهندگان می‌توانند با اطمینان سیستم امتیازدهی بازی بولینگ را بسازند و اصلاح کنند.
اعتبار سنجی ایمیل
در پروژهٔ توسعهٔ نرم‌افزار مایکروسافت، TDD می‌تواند برای پیاده‌سازی یک مؤلفهٔ اعتبارسنجی ایمیل قوی اعمال شود. فرایند TDD با نوشتن یک تست شکست‌خورده شروع می‌شود که رفتار تابع اعتبارسنجی ایمیل را تأیید می‌کند. آزمون اولیه می‌تواند قالب‌های ایمیل معتبر را بررسی کند و قالب‌های نامعتبر را رد کند. با نوشتن حداقل کد مورد نیاز برای قبولی در آزمون، توسعه‌دهندگان می‌توانند منطق اعتبارسنجی ایمیل را با استفاده از فناوری‌های Microsoft.NET پیاده‌سازی کنند. اجرای تست تضمین می‌کند که کد به درستی عمل می‌کند. تکرارهای بیشتر شامل اضافه کردن تست‌های بیش‌تر، مانند بررسی موارد لبه و مدیریت فرمت‌های مختلف ایمیل است. TDD تضمین می‌کند که مؤلفهٔ تأیید اعتبار ایمیل قابل اعتماد، دقیق است و می‌تواند سناریوهای مختلفی را در اکوسیستم Microsoft.NET مدیریت کند.
احراز هویت کاربر
در یک محیط توسعهٔ Microsoft.NET، توسعهٔ مبتنی بر آزمون می‌تواند برای توسعهٔ یک ماژول احراز هویت کاربر برای یک برنامه استفاده شود. این فرایند با نوشتن تست‌هایی آغاز می‌گردد که قابلیت‌های ورود و ثبت نام کاربر را با استفاده از فناوری‌ها و چارچوب‌های مایکروسافت تأیید می‌کند. تست‌های ناموفق تضمین می‌کنند که رفتار مورد نظر به درستی هدف قرار گرفته‌است. سپس حداقل کد مورد نیاز برای قبولی در آزمون‌ها با استفاده از ابزار Microsoft.NET پیاده‌سازی می‌شود. با اجرای تست‌ها، توسعه‌دهندگان می‌توانند منطق ورود و ثبت نام در اکوسیستم مایکروسافت را تأیید کنند. گسترش مکرر مجموعهٔ آزمایشی سناریوهایی مانند قدرت رمز عبور، بازیابی حساب و کنترل دسترسی مبتنی بر نقش را پوشش می‌دهد و از قابلیت‌های Microsoft.NET بهره می‌برد. TDD یک سیستم احراز هویت کاربر ایمن و قابل اعتماد را با اعتبارسنجی کامل کد پیاده‌سازی شده در برابر موارد آزمایشی با استفاده از فناوری‌های مایکروسافت تضمین می‌کند.