نقشه راه توسعه دهنده سی پلاس پلاس / Cpp developer roadmap

برای بزرگنمایی کلیک کنید

 

مروری بر Continuous Integration, Continuous Delivery, Continuous Deployment

دانلود مقاله

https://bayanbox.ir/view/327904009501239085/Overview-of-CI-CD.pdf

چند نکته در طراحی اصولی test case در Unit Test

• هر قطعه کد تست باید کوتاه، قابل فهم و خوانا باشه.
• کدهای تست باید قطعه قطعه و به واحدهای مستقل از هم تقسیم بشن.
• کدهای تست باید مستقل از محیط اجرایی باشن و وابستگی به platform نداشته باشن.
• بهتره شیوه اجرای کدهای تست بسادگی و توسط یک دستور انجام بشه.
• امکان گزارش گیری Test code coverage باید فراهم باشه.
• اجرای تست case ها از پایین ترین سطح(Unit) به بالاترین سطح(E2E) باید باشه.
• تست case هارو توسط الگوی AAA بنویسید.
• در کدهای تست باید از نقل/انتقال اطلاعات حجیم خودداری کرد تا پروسه تست بسرعت انجام بشه.
• کدهای تست باید بروز باشن و با هر تغییر جدی روی کدهای اصلی باید تغییر کنند.
• حجم کل کدهای تست تولید شده معمولاً باید برابر یا بیشتر از حجم کدهای اصلی باشه. (یعنی برای همه موارد تست نوشته شده باشه)
• کدهای تست باید در همان روزی که کدهای اصلی پروژه نوشته میشن تولید بشن. (به روزهای آینده موکول نشه)
• تست case ها باید کدها، متدها و امکانات پروژه رو به سخت ترین شکل به چالش بکشن.
• از test double ها استفاده مجدد کنید.
• تا حد امکان از تست کردن محتوای private کلاس ها و Private API ها پرهیز کنید. (بواسطه کدهای public تست blackbox انجام بدید یا CUT رو redesign کنید)
• هنگام نوشتن تست case تا حد امکان از بکار بردن دستورات شرطی if/else/switch... پرهیز کنید.
• بهتره کدهای تست به خارج از محدوده پروژه dependency نداشته باشن.
• بهتره نام فایل تست به کلمه Test ختم بشه. مثل EmailTest, UtilityTest, DatabaseTest
• بهتره نام توابع/متدهای داخل فایل تست با کلمه test شروع بشن. مثل test_if_email_is_valid یا testIsEmailValid
• همیشه تست هارو هم برای سناریوی happy path و هم unhappy path بنویسید. (تست happy path تضمین می کنه که سیستم در شرایط عادی به درستی کار می کنه، اما unhappy path به کشف و رسیدگی به مسائل مربوط به مدیریت خطا، امنیت و انعطاف پذیری در مواجهه با سناریوهای غیرمنتظره کمک می کنه.)

 

نکته: وظیفه نوشتن کدهای تست برای Unit Testing بعهده فرد برنامه نویس هستش نه فرد Tester. زیرا:

- بدلیل حفظ مالکیت کدها/پروژه، Tester نباید به سورس پروژه دسترسی داشته باشه.

- بدلیل مسایل امنیتی و کاهش تهدیدها، Tester نباید به داخل کدها و مکانیزم سیستم دسترسی داشته باشه.

- همچنین Tester قادر نیست به همه ابزارها، سبکها و زبانهای مختلفی که در پروژه استفاده شده مسلط بشه و test case طراحی کنه.

- تنها برنامه نویس هستش به کدهایی که پیاده سازی کرده مسلطه و test case رو در کمترین زمان با بالاترین کیفیت تولید میکنه.

انواع اصلی تست محصول نرم افزاری

 

Functionality test, Performance/Speed test, User experience test, Compatibility test, Security test

 

نکته: هر 5 نوع تست بالا رو میشه با 2 روش manual و automatic و در 5 سطح/لایه مختلف انجام داد:

Unit Test, Integration Test, Feature/Module Test. System Test, [User] Acceptance/E2E Test

مقایسه کوتاه بین FLTK, wxWidgets, Qt, GTK

مقایسه پرفورمنس(startup, rendering, event handling):

Windows platform
FLTK > wxWidgets > GTK > Qt

Linux platform
FLTK > GTK > (wxWidgets / Qt)

نکته: در اینجا منظور از GTK نسخه GTKmm هستش که wrapper/مخصوص  ++C  هستش.
نکته 2: عناصر کتابخانه  wxWidgets صددرصد native هستن. اما عناصر کتابخانه FLTK و Qt و GTK فقط "شبیه" به native هستن. که برای این شبیه سازی از CSS و API های theming سیستم استفاده می کنن.

این توضیحات رو هم در نظر بگیرید:
- کتابخانه FLTK از نظر استایل بهترین گزینه برای لینوکس با محیط EDE هستش. از نظر فضای دیسک، بسیار کم حجم هستش. پرفورمنس بالاتری نسبت به بقیه کتابخانه ها داره. استفاده ازش آسون هست. از بعضی دیگر زبانهای برنامه نویسی هم پشتیبانی میکنه. در ویندوز برروی WinAPI، در لینوکس برروی X Window و در مک بر روی Quartz سوار هست. FLTK بعضی از widget های مدرن مثل Treeview رو نداره. بعضی از widget ها حالت RTL (راست به چپ) رو ندارن.

 

- کتابخانه wxWidgets از نظر استایل بهترین گزینه برای ویندوز و مک و لینوکس هستش. از نظر فضای دیسک، حجیم هستش. یادگیری و استفاده ازش کمی سخته. UI designer هم داره. از خیلی زبانهای برنامه نویسی پشتیبانی میکنه. در لینوکس بر روی کتابخانه GTK قرار داره و در پشت پرده از API های GTK استفاده میکنه. wxWidgets فقط کتابخانه GUI نیست، یک فریم ورک محسوب میشه.

 

- کتابخانه GTK از نظر استایل بهترین گزینه برای لینوکس با محیط Cinnamon, GNOME, XFCE یا Mate هستش. یادگیری و استفاده ازش آسونه. UI designer هم داره. از خیلی زبانهای برنامه نویسی پشتیبانی میکنه.

 

- کتابخانه Qt از نظر استایل بهترین گزینه برای لینوکس با محیط KDE, TDE یا LXQt هستش. از نظر فضای دیسک، حجیم هستش. یادگیری و استفاده ازش بواسطه Qt Creator آسونه. UI designer هم داره. از خیلی زبانهای برنامه نویسی پشتیبانی میکنه. امکانات غیر استاندارد هم داره(meta-object). طیف گسترده تری از platform ها رو در بر گرفته. Qt فقط کتابخانه GUI نیست، یک فریم ورک هستش. برای پروژه های غیر opensource باید لایسنس داشته باشید. از مدل برنامه نویسی reactive پشتیبانی می کنه. (به کمک شتابدهنده گرافیکی میشه بار سنگین رندر رو از روی پردازنده برداشت، بنابراین باعث افزایش پرفورمنس میشه)

مقایسه الگوریتم binary search مقابل الگوریتم linear search

💡 مقایسه سرعت الگوریتم binary search مقابل الگوریتم linear search برای آرایه های مرتب شده(sorted)

(برای آرایه های عددی سنگین)

 

$needle = range(1, 500000);

 

❌ Linear search algorithm

function search(array $numbers, $needle)
{
   $_totalItems = count($numbers);

   for ($i = 0; $i < $_totalItems; $i ++)
   {
      if ($numbers[$i] === $needle)
      {
         return TRUE;
      }
   }

   return FALSE;
}

📊 نتیجه(ms)
0.031199932098389
0.031199932098389
0.031199932098389
0.031199932098389
0.031199932098389
0.031199932098389
0.031200170516968
0.031200170516968
0.046799898147583
0.046800851821899

 

✅ Binary search algorithm

function search(array $numbers, $needle)
{
   $_low = 0;
   $_high = count($numbers) - 1;

   while ($_low <= $_high)
   {
      $_middle = (int) (($_low + $_high) / 2);
      if ($numbers[$_middle] > $needle)
      {
         $_high = $_middle - 1;
      }
      else if ($numbers[$_middle] < $needle)
      {
         $_low = $_middle + 1;
      }
      else
      {
         return TRUE;
      }
   }

   return FALSE;
}

📊 نتیجه(ms)
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0

 

x64 Hardware
32bit OS
PHP 5.6 CLI

کد از کتاب "PHP 7 Data Structures and Algorithms"

مقدمه ای بر Virtual File System گنولینوکس

Virtual File System یا سیستم فایل مجازی

 

Virtual File System(مخفف VFS) یک ساب سیستم مهم در Kernel لینوکس هست که لایه بین filesystem و برنامه های user-space رو تشکیل میده. درواقع همه filesystem ها، با تکیه بر VFS می تونن شناسایی بشن و تبادل اطلاعات کنن. همین مسئله، برنامه های user-space رو قادر کرده که توسط دستورات موجود در VFS برای خواندن و نوشتن در filesystem های گوناگون اقدام کنن:

 

نکته: در اینجا منظور از لایه، همون Abstraction layer و منظور از دستورات، همون System call/SysCall هستش.

نکته 2: البته به برکت wrap های GNU C Library، کمتر پیش میاد که برنامه user-space نیاز به استفاده از System call داشته باشه.

مقایسه Android Studio و Eclipse

 

اول اینکه امکان توسعه برنامه های اندروید در Eclipse به 4 روش میتونه انجام بگیره:

1- توسط Eclipse نسخه Eclipse for Android Developers

2- توسط پلاگین Andmore و نصبش در Eclipse نسخه Eclipse for Java Developers

3- توسط پلاگین ADT و نصبش در Eclipse نسخه Eclipse for Java Developers(عدم پشتیبانی از material design و Android 7)

 

دوم اینکه توسعه پلاگین ADT توسط گوگل متوقف شده، اما دیگر پلاگینهای توسعه اندروید توسط برنامه نویسای مجرب آزاد کماکان داره بروز میشه... (چون اصل کار توسط SDK انجام میشه و نه پلاگین)

 

مقایسه مهمترین ها: (Eclipse و AS، نه IntelliJ)
اکلیپس یک بستر و IDE غول پیکر و مستقل هست با بیشترین پلاگین در بین IDE ها.
اندروید استودیو یک IDE و کپی از برنامه IntelliJ هست.

Module در Kernel لینوکس چیست

 

ماژول، قطعه ی نرم افزاری در بخشی جدا از Core هسته هستش که هنگام فراخونی شدن، پیوند و فعال میشه و یکسری عملیات تعریف شده ای رو انجام میده.
این ماژول می تونه سرویس باشه، filesystem باشه، پروتکل شبکه باشه، تعدادی System call باشه و یا درایور یک سخت افزار باشه; که در هر صورت ماژول نام داره.

ماژول ها در لینوکس به دو گروه تقسیم میشن:

1. Built-in kernel module
2. Loadable kernel module (یا LKM)

Built-in kernel module: که با قرار دادن سورس ماژول در داخل پوشه های سورس Kernel، همراه با Kernel کامپایل میشه.
Loadable Kernel module: که با load کردن ماژول کامپایل شده در داخل سیستم در حال اجرا فعال میشه.

دو قطعه کد برنامه ویندوزی

ExeStrip

این برنامه Header/Stup [داس] رو از فایل های Exe جدا می کنه.

BootSectorWriter

این برنامه 512 بایت از داده یا فایل رو روی سکتور بوت Write می کنه. (هارددیسک و فلاپی دیسک)