رفتن به مطلب
مرجع رسمی سی‌پلاس‌پلاس ایران

آی‌او‌استریم

نوشته‌های ویژه

  • کامبیز اسدزاده

    چشم‌انداز فنی برای کیوت ۶

    توسط کامبیز اسدزاده

    این چشم‌انداز احتمالاً برای دوست‌‌داران کتابخانهٔ قدرتمند Qt و طرفدارانش جذاب باشد! بنابراین من سعی کرده‌ام تا نتایج پست رسمی کیوت را در رابطه با چشم‌انداز فنی برای آیندهٔ کیوت نسخهٔ ۶ است در اختیار شما قرار دهم. تقریباً ۷ سال پیش کیوت نسخهٔ ۵.۰ منتشر شد! از آن زمان بسیاری از چیز‌ها در دنیای اطراف ما تغییر پیدا کرده است. و اکنون وقت آن رسیده است که چشم‌انداز جدیدی را از نسخهٔ جدید‌تر تعریف کنیم. بنابراین در این پست ما به معرفی مهمترین مواردی که به کیوت ۶ مرتبط است را می‌پردازیم. به نق
    • 6 دیدگاه
    • 3,334 مشاهده
  • کامبیز اسدزاده

    پشت پردهٔ تحریم‌های اپل و وضعیت کنونی اپلیکیشن‌های ایرانی

    توسط کامبیز اسدزاده

    مدتی است در مورد مسدود شدن اپلیکیشن‌های ایرانی برای iOS از طرف شرکت اپل خبر‌هایی به گوش می‌رسد که در سایت‌ها و پایگاه‌های خبری از سمت نویسندگان و افراد غیرفنی تجزیه تحلیل و روش‌های دور زدن آن‌ها ارائه می‌شود. واقعیت بر دلیل نوشتن این مقاله این است که این فرصت و مشکلات کنونی آبی گل‌آلود برای سود‌جویانی شده است که کاربران از آن بی‌خبرند! هر روز یک توسعه‌دهنده یک سایت جدید راه‌اندازی می‌کند و با ادعای ارائه بستری نامحدود اقدام به تبلیغات می‌کند. بنده نیز به عنوان توسعه‌دهنده وظیفهٔ خودم می‌دانم که
    • 0 دیدگاه
    • 1,868 مشاهده
  • کامبیز اسدزاده

    آیندهٔ توسعهٔ وب تحت فناوری WebAssembly

    توسط کامبیز اسدزاده

    با توجه به محبوبیت صنعت وِب، سال‌هاست زبان‌های برنامه‌نویسی در این زمینه پیشرفت‌ها و کاربرد‌های چشم‌گیری را داشته‌اند، از جمله جاوا‌اسکریپت (JS) به عنوان یک زبان قابل اجرا در داخل مرورگر شناخته می‌شود. هرچند بسیار محبوب و کاربردی است، اما این زبان قطعاً مشکلات خودش را دارد که برخی از آن‌ها عدم انعطاف‌پذیر بودن، سرعت پایین اجرا و همچنین انواع غیر ایمن آن است که این باعث می‌شود برای محاسبات و کارهای پیچیده جوابگو نباشد. هرچند گزینه‌هایی مانند CoffeeScript و TypeScript وجود دارند و نسبتا
    • 2 دیدگاه
    • 2,933 مشاهده
  • کامبیز اسدزاده

    فرق بین کامپایل استاتیک و داینامیک

    توسط کامبیز اسدزاده

    فرق بین کامپایل استاتیک و داینامیک قبل از اینکه فرق بین ایستا (استاتیک) - Static و پویا (داینامیک) - Dynamic را بدانیم لازم است در رابطه با چرخهٔ زندگی نوشتن یک برنامه و اجرای آن آشنا شویم. هر برنامه برای اولین بار توسط یک محیط توسعه (Editor) یا IDE توسط برنامه‌نویسان انتخاب و به صورت فایل متنی قابل ویرایش می‌باشد. سپس فایل متنی که شامل کد‌های نوشته شده توسط برنامه‌نویس تحت زبان برنامه‌نویسی مانند C، C++ و غیره... می‌باشد توسط کامپایلر به کد شیء ای تبدیل می‌شود که ماشین بتواند آن را درک کرد
    • 0 دیدگاه
    • 4,181 مشاهده
  • Max Base

    از تلفن همراه تا سکوی گیت هاب!

    توسط Max Base

    سلام. عدم دسترسی به یک سیستم مناسب و با خبر نبودن از حساب کاربری گیت هاب خود یکی از مشکلاتی بود که در این چند ساله برنامه نویسان با آن روبرو بودند. چک کردن حساب ایمیل در تلفن همراه می توانست تا حدودی به این موضوع کمک کند. اما یک اپلیکیشن اختصاصی برای این مورد می تواند این امر را به بهترین شکل پوشش دهد. بعد از کارهایی که برروی اپلیکیشن رسمی شرکت گیت هاب برای پلتفرم iOS انجام شد و خوشبختانه بدون هیچ مشکلی در بزرگ رویداد و کنفرانس شرکت و مایکروسافت - GitHub Universe 2019 در تاریخ Nov
    • 1 دیدگاه
    • 1,069 مشاهده

وبلاگ‌های سایت ما

  1. یکی از مهمترین و پر‌مخاطب‌ترین سوألاتی که در مورد فریم‌ورک کیوت پرسیده می‌شود، شرایط استفاده و مجوز‌های مربوط به آن است؛ از آنجایی که این کتابخانه تحت پشتیبانی یک شرکت تجاری است، برخی از شرایط و قوائدی وضع شده است که در استفاده از آن باید دقت لازم را داشت. در این مقاله من قصد دارم به توضیحات و شفاف‌سازی کامل در این خصوص بپردازم که امیدوارم از آن بهره‌مند شده و به اشتراک بگذارید.

    qtlicense.jpg

    بررسی مجوز‌های جامع Qt

    ابزار Qt، یک چهارچوب قدرتمند برنامه‌نویسی چندسکویی است که انواع مختلفی از مجوزها را ارائه می‌دهد تا به نیازهای متنوع کاربران خود پاسخ دهد. با توجه به تاریخچهٔ غنی‌ای که به آغاز توسعهٔ آن باز می‌گردد، Qt به تدریج به یکی از اصلی‌ترین بازیگران در زمینه توسعه نرم‌افزار تبدیل شده است که در این مقاله به آن اشاره می‌کنیم.

    Qt تحت چندین گزینه مجوز مختلف قرار دارد که برای توسعه نرم‌افزارهای مختلف مناسب هستند که به صورت زیر تعریف شده‌اند.

    1. مجوز تجاری Qt
      • فریم‌ورک کیوت، زیر مجوزهای تجاری مناسبی را برای توسعه نرم‌افزارهای تجاری فراهم کرده است که کاربران نمی‌خواهند کد منبع خود را با دیگران به اشتراک بگذارند یا نمی‌توانند با شرایط نسخه 3 مجوز GNU LGPL (GNU Lesser General Public License) سازگاری یابند.
    2. مجوز LGPL Qt
    3. مجوز بازار Qt (Qt Marketplace)
    • اجزای Qt تحت توافق‌نامه مجوز بازار Qt مناسب برای توسعه نرم‌افزارهای Qt هستند، معمولاً با شرایط مجوز تجاری یا GNU LGPL (یا GNU GPL نسخه 3) برنامه‌ریزی می‌شوند.

    استفاده از کد، از طریق مجوزهای متن‌باز

    فریم‌ورک Qt شامل کدهای شخص ثالثی است که تحت مجوزهای خاص متن‌باز از نویسندگان اصلی مجوزدهی شده‌اند.

    نقل قول

    توجه: برخی از اجزاء (ماژول‌ها) در Qt که تحت مجوز GNU LGPL نسخه 3 موجود نیستند، بلکه تحت مجوز GNU GPL (GNU General Public License) قرار دارند. برای اطلاعات بیشتر، لیست ماژول‌های Qt را مشاهده کنید.

    برخی از سوأل و پرسش‌های جامعه و تیم کیوت در رابطه با مجوز‌ها و اهداف آن‌ها در توسعه

    چرا Qt همچنین زیر مجوز نرم‌افزار متن باز نیز منتشر می‌شود؟

    ما به جنبش نرم‌افزار آزاد اعتقاد داریم که استفاده از نرم‌افزار با حقوق وظایف خاصی همراه است. استفاده از مجوزهای نرم‌افزار متن باز، به کاربران چهار درجه اصلی از آزادی را در استفاده از برنامه‌ها یا دستگاه‌های Qt می‌دهد:

    1. آزادی اجرای برنامه برای هر هدفی.
    2. آزادی مطالعه نحوه عمل برنامه و سازگارسازی آن با نیازهای خاص.
    3. آزادی توزیع نسخه‌های کپی شده تا بتوانید به همسایه خود کمک کنید.
    4. آزادی بهبود برنامه و انتشار بهبود‌های خود به عموم، تا کل جامعه بهره‌مند شود.

    این آزادی‌ها غیرقابل مذاکره و مطلق هستند، نمی‌توان آنها را به صورت انتخابی یا جزئی تجربه کرد، شما همچنین موظف به انتقال آنها به کاربران خود هستید.

    نقل قول

    جامعه نرم‌افزار آزاد به دلیل این قوانین به رشد پیشرفت کرده است، اما همچنین توسعه‌دهندگانی وجود دارند که هرگز نقشه ندارند یا نمی‌توانند این قوانین را رعایت کنند و بنابراین باید مجوز تجاری بگیرند. شرکت Qt برای حمایت از هر دو گروه با ارائه مجوزهای دوگانه وجود دارد.

    چرا شما توافقی با KDE در مورد مجوزهای خود دارید؟ KDE چیست و تاریخچهٔ Qt و KDE چگونه است؟

    توافق بین Qt و KDE دربارهٔ مجوزها، ریشه در تاریخچهٔ مشترک این دو نهاد دارد. KDE (kde.org) مخفف محیط کاری دسکتاپ (Desktop Environment) است که یک جامعهٔ بین‌المللی نرم‌افزار آزاد است و در سال ۱۹۹۶ تأسیس شد. KDE به خاطر محیط کاری Plasma Desktop شناخته می‌شود که به عنوان محیط کاری پیش‌فرض در بسیاری از توزیع‌های لینوکس به کار می‌رود. نرم‌افزارهای KDE بر پایهٔ چارچوب Qt ساخته می‌شوند. در اوایل توسعهٔ Qt، این چارچوب از یک مدل مجوز دوگانه برخوردار بود و کد منبع آن تحت مجوزهای متن باز اختصاصی قابل دسترس بود. با درک اهمیت Qt برای پروژه‌های خود، KDE تلاش کرد تا توافقاتی برای اطمینان از دسترسی به Qt تحت مجوزهای مناسب متن باز، حتی اگر Trolltech (شرکت بنیان‌گذار Qt) به تصرف بشود یا ورشکست شود، به دست آورد. نتیجهٔ این تفاهم، بنیاد آزاد KDE Qt (KDE Free Qt Foundation) تأسیس شد و توافق‌نامه بنیاد آزاد KDE Qt ایجاد شد.

    بنیاد آزاد KDE Qt یک سازمان با هدف ایمن کردن دسترسی به چارچوب Qt برای توسعهٔ نرم‌افزارهای آزاد و به‌ویژه برای توسعهٔ نرم‌افزارهای KDE است. این بنیاد در ابتدا توسط Trolltech و سازمان غیرانتفاعی حقوقی KDE (KDE e.V.) در سال ۱۹۹۸ تأسیس شد و یک توافق‌نامهٔ مجوز دارد که تأمین می‌کند که Qt برای پلتفرم‌های اصلی دسکتاپ و موبایل تحت مجوزهای LGPLv3 و GPLv3 در دسترس است. این توافق‌نامه در طی سال‌ها چندین بار به‌روزرسانی شده است، عمدتاً به دلیل انجام معاملات مرتبط با Qt یا به‌روزرسانی مجوزها و پلتفرم‌ها.

     

    عدم رعایت محدودیت‌های مجوزهای LGPL/GPL چه تبعاتی دارد؟

    اگر نرم‌افزاری که از این کتابخانه‌های مجوز متن‌باز استفاده می‌کند، به طور کامل الزامات مجوز را رعایت نکند، شما حق استفادهٔ مجوز و حقوق توزیع مرتبط با آن را از دست خواهید داد. همچنین لازم به ذکر است که در بیشتر کشورها، نقض حقوق نسخهٔ پدیدآورندگان یک نقض تشریعی است، نه نقض قرارداد، و بنابراین تدابیر تشریعی مرتبط با این موضوع اعمال می‌شود. برای کسب اطلاعات بیشتر در مورد GPL، می‌توانید به صفحه FAQ GPL از لینک آن مراجعه کنید.

     

    آیا می‌توانم از نسخهٔ متن باز جوامع برای توسعه محصول تجاری خود استفاده کنم؟

    این بستگی به نحوهٔ ارائه و ارائهٔ محصول شما دارد. نسخهٔ متن باز Qt اصلی به طور عمده تحت مجوز LGPL نسخه 3 و GPLv2/v3 منتشر می‌شود. شما باید الزامات مجوزهای این گونه را که در زمان استفاده از Qt در محصول خود باید رعایت کنید.

     

    تفاوت بین LGPLv2 و LGPLv3 چیست؟

    LGPLv3 نسخه فعلی مجوز GNU Lesser General Public License است. LGPLv2.1 یک نسخه قدیمی‌تر است و برای پروژه‌های جدید توصیه نمی‌شود. هر دو مجوز همان هدف را دارند، یعنی حفاظت از آزادی کاربران برای استفاده و اصلاح نرم‌افزار تحت مجوز LGPL.

    LGPLv3 این هدف را به وضوح بیان می‌کند. شما باید چیز‌هایی را برای کاربر نهایی فراهم کنید تا نسخه اصلاح شدهٔ کتابخانه تحت مجوز LGPLv3 را نصب کرده و نرم‌افزار خود را با استفاده از آن کتابخانه اصلاح شده اجرا کند. در عمل، این به عنوان مثال به موارد زیر اشاره دارد:

    • Tivoization – به وضوح اجازه ندهید دستگاه‌های بسته سازی‌شده ایجاد شود که کاربر نهایی حقوق مجوز LGPL برای کتابخانه‌های متن باز Qt را ندارد.
    • DRM و رمزگذاری سخت‌افزاری – نمی‌توان از این تعهدات برای دور زدن این تعهدات استفاده کرد.
    • انتقام از پتنت نرم‌افزار – جایی که تمام کاربران نرم‌افزار مجوزها را دارند، که این باعث بی‌معنی شدن انتقام از پتنت نرم‌افزارهایی که ممکن است در نرم‌افزار منتشر شده، می‌شود.

     

    وظایف من چیستند هنگام استفاده از Qt تحت مجوز LGPL؟

    در ابتدا، باید توجه داشته باشید که تمامی ماژول‌های متن باز Qt تحت مجوز LGPLv3 در دسترس نیستند. برخی از ماژول‌ها برای استفاده در نرم‌افزارهای متن باز تحت GPLv3 قرار دارند و برخی از اجزاء توسعه‌یافته توسط شخص ثالث مانند موتور وب Chromium تحت مجوز LGPLv2.1 در دسترس قرار گرفته‌اند.

    زمانی که از ماژول‌ها و کتابخانه‌های Qt تحت مجوز LGPLv3 استفاده می‌کنید، برخی از وظایفی که باید رعایت کنید به شرح زیر است:

    1. هنگام استفاده از نرم‌افزار متن باز، باید از مجوز هر نمونه، قطعه کد منبع، ماژول و کتابخانه‌ای که در پروژه خود استفاده می‌کنید، آگاه باشید و مجوزهای مرتبط را ردیابی کنید.
    2. باید کد منبع کامل کتابخانه‌های Qt که استفاده کرده‌اید را به همراه تمام اصلاحات اعمال شده یا اعمال شده، به کاربران یا مشتریان خود ارائه دهید. به عنوان یک گزینه دیگر، می‌توانید پیشنهاد نامه‌ای با دستورالعمل‌هایی در مورد چگونگی دریافت کد منبع ارائه دهید. لطفاً توجه داشته باشید که این باید تحت کنترل شما باشد، بنابراین ارائه یک لینک به کد منبع ارائه‌شده توسط پروژه Qt یا شرکت Qt کافی نیست.
    3. مجوز LGPL به شما این امکان را می‌دهد که کد منبع خود نرم‌افزار را به عنوان «کاری که از کتابخانه استفاده می‌کند» خصوصی نگه‌دارید. به طور معمول، در اینجا پیشنهاد می‌شود که از اتصال پویا استفاده کنید (برای کامپایل استاتیک این مورد مجاز نیست و نیاز به تهیهٔ مجوز دارد).
    4. کاربر نهایی باید قادر باشد نرم‌افزار شما را با یک نسخه مختلف یا اصلاح‌شده از کتابخانه Qt مجدداً لینک کند. با LGPLv3، به وضوح ذکر شده است که کاربر باید قادر باشد باینری مجدداً لینک‌شده را بر روی دستگاه هدف خود اجرا کند. این وظیفه به شما محول است که کاربر را با همه ابزارهای لازم برای فعال کردن این فرآیند تجهیز کنید. برای دستگاه‌های جاسازی‌شده، این شامل فراهم‌کردن تمام ابزارهایی است که برای کامپایل کتابخانه استفاده‌شده به کاربران مورد نیاز است. برای اجزاء مجوزده LGPLv3، شما موظف به ارائه دستورالعمل‌های کامل در مورد نصب کتابخانه اصلاح‌شده بر روی دستگاه هدف هستید (این با LGPLv2.1 به طور واضح بیان نشده است، اگرچه اجرای برنامه در برابر نسخهٔ اصلاح شدهٔ کتابخانه با هدف اعلام شده در مجوز است).
    5. کاربری که از یک برنامه یا دستگاه که از نرم‌افزار متن باز تحت مجوز LGPL استفاده می‌کند، باید از حقوق خود مطلع شود، با ارائه یک نسخه از مجوز LGPL به کاربر نهایی و نمایش اعلان مشهور در مورد استفاده‌ شما از نرم‌افزار متن باز باید اعلام شود.
    6. این آزادی‌ها به هیچ وجه توسط شرایط دیگر مجوز گزینشی نمی‌توانند محدود شوند؛ اگر یک برنامه به کلی از تمام وظایفی که در بالا ذکر شده است پیروی نکند، اجازه توزیع آن به هیچ وجه داده نمی‌شود.
    7. همچنین باید اطمینان حاصل کنید که از هیچ ماژولی که تحت مجوز GPL استفاده نمی‌کنید.

     

    آیا نیاز است که از مجوز LGPL هنگام استفاده از نسخهٔ تجاری Qt نگران باشم؟

    به طور معمول، خیر. هنگام استفاده از نسخهٔ تجاری مجوزگذاری شده Qt، ما تقریباً تمامی بخش‌ها را تحت شرایط یک مجوز تجاری ارائه می‌دهیم.

    هرچند، چندین ماژول در Qt از کد منبع پروژه‌های متن باز شخص ثالث مانند Qt WebEngine استفاده می‌کنند که از پروژه Chromium با مجوز LGPLv2.1 استفاده می‌کند. بنابراین، هنگام استفاده از این ماژول‌ها، شما باید از تعهدات مجوز مرتبط رعایت کنید، در مورد Chromium این موضوع به مجوز LGPLv2.1 اشاره دارد.

    تمامی ماژول‌ها و وابستگی‌های شخص ثالثی که توسط ماژول‌های مختلف Qt استفاده می‌شوند، در مستندات Qt برای هر نسخه از Qt مستند شده‌اند.

    به عنوان یک کاربر مجوز تجاری، در عمل، تنها نیاز دارید که به تعهدات مجوز LGPLv2.1 اهمیت بدهید، و تنها اگر از Qt WebEngine استفاده کنید.

     

    چه کاری باید انجام دهم؟

    مطمئن نیستم که مطابق مجوزهای متن باز هستم؟ از مجوزهای متن باز گیج شده‌ام، چه باید انجام دهم؟

    همیشه خوشحال هستیم که با شما درباره وضعیتتان صحبت کنیم، اما ما در جایی نیستیم که مشاوره حقوقی ارائه دهیم. همیشه توصیه می‌شود با یک وکیل که با مجوزهای متن باز آشنا است، تماس بگیرید تا یک بررسی کامل از پروژه شما صورت گیرد و تصمیم گیری شود که آیا شما می‌توانید تمامی تعهدات مجوزهای متن باز مربوطه (مانند LGPLv/GPLv) را انجام دهید یا خیر.

     

    مجوز تجاری Qt چگونه کار می کند؟ آیا همه توسعه دهندگان من باید مجوز معتبر Qt داشته باشند؟

    در رابطه با مجوز‌های تجاری، هر کاربر Qt باید مجوز تجاری Qt مختص خود را داشته باشد. طراحان رابط کاربری، هنرمندان فنی، توسعه‌دهندگان نرم‌افزار یا مهندسان اتوماسیون تست ممکن است انواع مختلفی از مجوزهای Qt داشته باشند، اما هر فرد باید یک مجوز اشتراک معتبر داشته باشد.

     

    آیا می‌توانم کد نوشته‌شده با Qt متن باز را با Qt تجاری مجوزگذاری شده ترکیب کنم؟

    خیر.

    اگر می‌خواهید از Qt متن باز به یک مجوز تجاری مهاجرت کنید، لطفاً با فروشگاه Qt تماس بگیرید.

    برای این سوال، موارد بیشتری نیز در لینک FAQ مجوزگذاری تجاری Qt وجود دارد.

     

    آیا امکان توزیع برنامه‌های توسعه یافته با نسخهٔ متن باز Qt از طریق فروشگاه‌های عمومی وجود دارد؟

    هر فروشگاه اپلیکیشن شرایط و مقررات منحصر به فردی دارد که ممکن است با توزیع برنامه‌ها تحت مجوزهای LGPL یا GPL سازگار یا سازگار نباشد.

    مجوز تجاری Qt با شرایط و مقررات تمامی فروشگاه‌های اپلیکیشن معتبر سازگار است و بنابراین معمولاً بهترین گزینه برای توزیع یک برنامه به صورت منبع بسته در فروشگاه‌های مختلف است.

     

    من شروع به توسعه یک محصول با استفاده از نسخهٔ متن باز Qt کرده‌ام، حالا می‌توانم یک نسخهٔ تجاری از Qt خریداری کرده و کدم را تحت آن مجوز قرار دهم؟

    بله. پروژه‌های توزیع‌شده تحت نسخهٔ تجاری Qt نیز باید تحت نسخهٔ تجاری Qt توسعه یابند.

    اگر قبلاً توسعه را با نسخهٔ متن باز Qt شروع کرده‌اید، ما به همکاری برای یافتن یک راه‌حل برای انتقال پایه کد شما از حاکمیت متن باز به مجوز تجاری می‌پردازیم.

    اگر از ابتدا مطمئن نیستید که از کدام مجوز یا نسخه برای شروع توسعه استفاده کنید، توصیه می‌شود با The Qt Company تماس بگیرید تا بر اساس نیازهای توسعه‌ی خود شما راهنمایی شود.

     

    ممکن است در یک برنامه از کتابخانه‌های دارای مجوز LGPLv2.1 و LGPLv3 استفاده کرد؟

    بله، امکان استفاده از هر دو نسخهٔ مجوز LGPLv2.1 و LGPLv3 در یک برنامه وجود دارد، به عنوان مثال با استفاده از آن‌ها به عنوان کتابخانه‌های جداگانه به عنوان shared libraries. انجام این کار نیاز به تغییر مجوز در هیچ یک از کتابخانه‌ها ندارد و در صورت نیاز، امکان انتخاب یک مجوز مولد برای برنامه وجود دارد.

     

    ماتریس سازگاری GNU نشان می‌دهد که من نمی‌توانم LGPLv2 و LGPLv3 را ترکیب کنم؟

    اگر کد LGPLv2.1 و کد LGPLv3 در کتابخانه‌های جداگانه به عنوان shared libraries قرار داده شوند، می‌توانند در یک برنامه استفاده شوند، و شما می‌توانید برنامه خود را با یک مجوز مالکیتی / LGPLv2.1 / LGPLv3 به دلخواه خود مجوزگذاری کنید.

     

    در مورد نسخهٔ مجوز LGPL/GPL که شما استفاده می‌کنید، چه کسانی مهم هستند؟

    شما، مشتریان شما و کاربران نهایی، مگر اینکه از Qt تحت یک مجوز تجاری استفاده کنید. مجوزهای copyleft مانند LGPL و GPL به این معناست که مجوز با محصول شما به مشتریان و کاربران یا راه‌حل شما همراه می‌شود.

     

    با توجه به تمامی توضیحات موجود، به طور خلاصه چه زمانی نیاز به تهیهٔ مجوز‌های کیوت داریم؟

    تهیهٔ مجوز کتابخانه Qt بستگی به نوع کاربرد و نیازهای پروژه دارد. جوانب مختلفی که تعیین می‌کنند چه زمانی نیاز به مجوز Qt داریم و چه مواردی ممکن است بدون نیاز به مجوز باشند.

    1. استفادهٔ شخصی:
      • نیاز به مجوز: اگر برنامه‌نویس قصد استفاده از Qt را برای توسعهٔ پروژهٔ شخصی و خصوصی دارد بدون انتشار کد منبع، نیاز به مجوز ندارد. در این حالت، می‌توان از Qt به صورت رایگان استفاده کرد.
      • بدون نیاز به مجوز: استفاده از Qt برای پروژه‌های شخصی بدون هدف انتشار کد منبع با محدودیتی همراه نخواهد بود.
    2. توسعهٔ نرم‌افزار باز (Open Source):
      • نیاز به مجوز: اگر قصد توسعهٔ یک نرم‌افزار منبع باز با Qt را دارید و می‌خواهید کد منبع خود را نیز تحت یک مجوز Open Source انتشار دهید، نیاز به مجوز GPL یا LGPL خواهید داشت.
      • بدون نیاز به مجوز: اگر نیازی به انتشار کد منبع ندارید و از Qt برای پروژه منبع باز خود استفاده می‌کنید، می‌توانید از نسخهٔ Qt با مجوز LGPL بدون مشکل استفاده کنید.
    3. توسعهٔ نرم‌افزار تجاری (Commercial Software):
      • نیاز به مجوز: اگر قصد توسعهٔ نرم‌افزار تجاری دارید و نمی‌خواهید کد منبع خود را انتشار دهید، نیاز به مجوز تجاری Qt دارید.
      • بدون نیاز به مجوز: اگر از Qt برای توسعهٔ یک نرم‌افزار تجاری استفاده می‌کنید و توافق به اشتراک‌گذاری کد منبع ندارید، می‌توانید از نسخهٔ تجاری Qt بهره‌مند شوید.
    4. توسعهٔ نرم‌افزار تحت LGPL:
      • نیاز به مجوز: اگر می‌خواهید نرم‌افزار تجاری توسعه دهید، اما نیاز به استفاده از کتابخانه Qt دارید و می‌خواهید تغییرات خود را در کتابخانه منتشر کنید، باید از مجوز LGPL استفاده کنید.
      • بدون نیاز به مجوز: اگر قصد استفاده از Qt را در یک نرم‌افزار تجاری با حفظ محرمانگی کد دارید، می‌توانید از مجوز تجاری Qt بهره‌مند شوید.

    برخی از نکات را نیز باید در نظر بگیرید، مانند نوع کامپایل و نوع مجوز‌های قابل پذیرش در فروشگاه‌ها که عموماً همهٔ آن‌ها را توضیح دادیم به چه صورت هستند.

  2. بیت‌کوین در سال ۲۰۰۹ به عنوان یک ارز دیجیتال و یک پلتفرم غیرمتمرکز همتا به همتا راه انداخته شد که کنترل اموال را به همه افراد می‌دهد. ساتوشی ناکاموتو این پلتفرم را معرفی کرد و از آن زمان به کاربری گسترده رسیده و سرمایه‌گذاری با ارزش بازار بیش از ۳۵۳ میلیارد دلاری را به دست آورده است. به عنوان یک گزینه سرمایه‌گذاری، بیت‌کوین دارای ماهیت نوسانی است و برای افرادی که حاضر به پذیرش ریسک هستند، ثروت‌آفرین بوده است. حتی برخی از متخصصان مالی ادعا می‌کنند که قیمت یک بیت‌کوین ممکن است در چند سال آینده به بیش از ۴۰۰ هزار دلار برسد، این که این دارایی بهتر از طلا به عنوان یک ذخیره ارز باشد.

    cppwp.png.ae82f7a309847619e252c8a748456623.png

    فناوری مورد استفاده در بیت کوین نیز در نوع خود بی نظیر است. ناکاموتو استفاده از الگوریتم های ++C را برای طراحی این فناوری مالی انتخاب کرد، اما چرا؟
     

    مدیریت حافظه

    مدیریت منابع یکی از حیاتی‌ترین مسائلی است که توسعه‌دهندگان در هنگام ایجاد نرم‌افزار در نظر می‌گیرند. برای اینکه یک نرم‌افزار بتواند کلیه ویژگی‌های خود را به دست آورده و همچنان در ارائه خدمات بسیار موثر باقی بماند، باید پروتکل‌های مناسب مدیریت منابع داشته باشد.

    در توسعه بلاکچین، وضعیت تا حد زیادی تفاوت ندارد. از آنجا که بلاکچین خدماتی را به میلیون‌ها نفر و نهاد ارائه می‌دهد، باید برای کارایی در ارائه خدمات بسیار مقیاس‌پذیر باشد. تحقیقات اخیر از Statista نشان می‌دهد که شبکه بیت‌کوین در سومین سه‌ماه سال ۲۰۲۰ بیش از ۳۵۰ هزار تراکنش روزانه داشت.

    بعضی از این تراکنش‌ها شامل مقادیر زیادی پول دیجیتال هستند و به عنوان نتیجه نیاز به محاسبات طولانی دارند. ایده اصلی ایجاد بلاکچین توسط ناکاموتو، ایجاد یک شبکه برای تسهیل تعاملات مالی و تسریع در فرآیندها بود. بهترین زبان برنامه‌نویسی برای یک سیستم با این ویژگی‌ها الگوریتم‌های سی‌پلاس‌پلاس است.

    الگوریتم‌های سی‌پلاس‌پلاس می‌توانند با استفاده بهینه از منابع و کنترل بر روی استفاده از CPU و حافظه، در سطح بهترین عمل کنند. این الگوریتم همچنین به بلاکچین اجازه می‌دهد تا بلوک‌ها را پذیرفته یا رد کند، بنابراین هر گونه تفکیک در بلاکچین را از بین می‌برد. استفاده از C++ بنابراین به پلتفرم کمک می‌کند تا با نرخ سریع با نقاط پایان مختلف تعامل کند.

     

    جداسازی کد

    توسعه نرم‌افزار، شامل بلاکچین، باید فضای کافی برای عملیات تعیین‌پذیر فراهم کند. در مورد بلاکچین، عملکردهای تعیین‌پذیر، هنگامی که به درستی اجرا می‌شوند، تضمین می‌کنند که تراکنش‌ها و فرآیندهای داخلی مانند قراردادهای هوشمند همواره به یک شیوه خدمت می‌کنند حتی زمانی که در دستگاه‌های مختلف قرار دارند.

    اما تنها راه توسعه‌دهندگان و متخصصان کد نحوه دستیابی کامل به عملیات تعیین‌پذیر را اعمال جداسازی کدها می‌دانند. چه چیزهایی باید توسعه‌دهندگان جدا کنند؟ از آنجا که عملکردهای اجرا شده تعیین‌پذیر هستند، توسعه‌دهندگان باید راهی برای جدا کردن عناصر غیرتعیین‌پذیر از کد قرار دهند.

    سی‌پلاس‌پلاس از قابلیت‌های فضای نام (namespace) بهره‌مند است که به برنامه‌های دیگر قابل انتقال هستند. این فضاهای نام به جلوگیری از تداخل در عملکرد کدها کمک می‌کنند. همچنین ویژگی کلاس وجود دارد که به جدا کردن و تعیین مرزها بین API کمک می‌کند.

     

    قابلیت اطمینان و رسالت ++C

    یکی از ویژگی‌های حیاتی دیگری که به انتخاب ساتوشی ناکاموتو از سی‌پلاس‌پلاس به عنوان زبان اصلی برنامه‌نویسی بیت‌کوین کمک کرد، ویرایش و به‌روز رسانی‌های اساسی سی‌پلاس‌پلاس است. ++C اغلب به‌روزرسانی می‌شود تا اطمینان حاصل شود که همواره باقی بماند و قابل اطمینان و به‌روز باشد.

    علاوه بر این، ++C دارای ابزارهای دیباگ و تجزیه و تحلیل مختلف است، تمامی این ابزارها به تقویت عملکرد آن کمک می‌کنند. این ابزارها همچنین امکان شناسایی هر مشکلی را در زمان برنامه‌نویسی فراهم می‌کنند. قابلیت اطمینان و ویرایش سی‌پلاس‌پلاس آن را به پایدارترین زبان برنامه‌نویسی برای توسعه بیت‌کوین تبدیل می‌کند که همچنین اطمینان می‌دهد که نرم‌افزار ساخته شده دارای امنیت بسیار بالاتری باشد.

     

    نخ‌ها (Threading)

    نخ‌ها یا ترد، در برنامه‌نویسی شامل یک مجموعه از دستورالعمل‌ها، فعالیت‌ها یا وظایفی هستند که می‌توانند به طور صاف یا هماهنگ با یکدیگر اجرا شوند. دو نوع عملکرد باید در هر نرم‌افزار یکپارچه باشند، یعنی وظایف موازی و غیرموازی.

    یک پروژه بلاکچین بیت‌کوین هرگز نمی‌توانست کار کند اگر وظایف موازی و غیرموازی هماهنگ عمل نمی‌کردند. اما یکی از پیچیده‌ترین چیزها در برنامه‌نویسی، ادغام این وظایف است و بیشتر زبان‌های برنامه‌نویسی در حال حاضر معمولاً تمرکز بر روی یکی از این دو وظیفه، یعنی موازی یا غیرموازی دارند.

    اما سی‌پلاس‌پلاس یکی از قابلیت‌های نخی قابل تحسین دارد که توسعه‌دهنده را قادر می‌سازد همزمان از هر دو وظیفه موازی و غیرموازی استفاده کند. سی‌پلاس‌پلاس می‌تواند به‌طور کارآمد نخ‌های چندگانه را اجرا کرده و امکان ارتباط همگانی و قابل اعتماد بین تمام نخ‌ها را فراهم کند.

    علاوه بر این، نخ‌های ایجاد شده توسط سی‌پلاس‌پلاس می‌توانند در نقطه بهینه‌ترین عمل کنند، بنابراین کل بلاکچین به طور بهینه عمل می‌کند. با توجه به عملکرد بهینه این زبان، می‌توان گفت یک دلیل دیگر که ساتوشی ناکاموتو از سی‌پلاس‌پلاس استفاده کرد، این است که این زبان امکان نخبندی آسان برای وظایف موازی و غیرموازی را فراهم می‌کند.

     

    قابلیت (Move Semantics)

    قابلیت (Move Semantics) یک عملکرد است که به توسعه‌دهندگان امکان می‌دهد محتوا را بین اشیاء جابجا کنند به جای اینکه فقط محتوا را کپی کنند. با استفاده از قابلیت جابه‌جایی اشیاء و ...، توسعه‌دهندگان و کاربران بر اساس نیاز دسترسی به کپی‌های مختلف اطلاعات دارند، که عملکرد را افزایش داده و تکرار را کاهش می‌دهد.

     

    تبعیت از استاندارد‌ها و رعایت قوائد انرژی سبز

    انرژی سبز یکی از چالش‌های اصلی در صنعت بلاکچین و تولید بیت‌کوین است. به دلیل محاسبات پیچیده و فرآیند استخراج معدنی که برای تولید بیت‌کوین انجام می‌شود، مصرف انرژی این فعالیت‌ها به سرعت افزایش می‌یابد.

    سی‌پلاس‌پلاس به عنوان زبان اصلی برنامه‌نویسی بیت‌کوین، به طور چشمگیری به بهینه‌سازی مصرف انرژی متمایل است. استانداردهای مصرف بهینه انرژی در طراحی و اجرای برنامه‌ها، این زبان را به یک انتخاب پایدار برای پروژه‌های مرتبط با بلاکچین و ارزهای دیجیتال می‌کند. این به معنای کاهش آثار منفی بر محیط زیست و همچنین صرفه‌جویی در هزینه‌های انرژی مرتبط با فرآیند تولید بیت‌کوین می‌باشد.

    همچنین، با توجه به گستردگی بیت‌کوین و تاثیر زیاد آن بر مصرف انرژی جهان، تلاش برای استفاده از زبان‌های برنامه‌نویسی با بهینه‌ترین مصرف انرژی، اهمیت فوق‌العاده‌ای پیدا کرده است. سی‌پلاس‌پلاس با امکانات بهینه‌سازی و مدیریت منابع به کاربران این امکان را می‌دهد که به نحوی کارایی انرژی را بهبود بخشند و در طولانی مدت، اثرات محیطی مرتبط با تولید بیت‌کوین را کاهش دهند. از این رو، اهمیت انتخاب این زبان برای توسعه بیت‌کوین نه تنها در جنبه‌های فنی بلکه در جنبه‌های محیطی نیز بیان می‌شود.

     

    بهتر است نظر سازندهٔ سی‌پلاس‌پلاس در مورد استفاده از این ابزار برای ارز دیجیتال را هم بدانیم

    در اشتراک بین خالق زبان برنامه‌نویسی سی‌پلاس‌پلاس، بیارنه استرواستروپ و ساتوشی ناکاموتو، اشاره به زبان برنامه‌نویسی ++C و موضوع ماینینگ بیت‌کوین با تأکید بر مصرف انرژی بالا و تأثیرات آن بر محیط زیست است. چندی پیش در یک پادکست هوش مصنوعی با مجری Lex Fridman، استرواستروپ در مورد نحوهٔ استفاده از سی‌پلاس‌پلاس و عدم کنترل بر نحوه استفاده از ابزارهای توسعه‌دهنده صحبت کرده و به‌ویژه به ماینینگ بیت‌کوین اشاره کرده است. او به عنوان خالق زبان سی‌پلاس‌پلاس ابراز خوشحالی از برخی از کاربردهای این زبان و ناراحتی از برخی دیگر اشاره کرده و به مصرف انرژی بالای ماینینگ بیت‌کوین اشاره کرده است.

    استرواستروپ از مصرف انرژی فعلی ماینینگ بیت‌کوین به خوشایندی خاصی احساس نمی‌کند و این موضوع را به دلیل انتخاب سی‌پلاس‌پلاس به عنوان زبان برنامه‌نویسی توسعه بیت‌کوین توسط ساتوشی ناکاموتو ذکر کرده است.

    از نظر استراس‌تروپ سی‌پلاس‌پلاس، یک زبان برنامه‌نویسی قدرتمند و گسترده است که در حوزه‌های مختلف برنامه‌نویسی مورد استفاده قرار می‌گیرد. این زبان امکانات بالایی برای مدیریت حافظه، کارایی بالا، و امکانات چندپارادیمی (مانند برنامه‌نویسی شیءگرا) فراهم می‌کند که در سراسر منابع کد بیت‌کوین شاهد آن هستیم. اما عامل ناراحتی او، مصرف انرژی بالا ممکن است که به علت نحوه استفاده یا پیاده‌سازی خاص از زبان و ابزارهای مرتبط با آن باشد و نه ضعف اساسی زبان سی‌پلاس‌پلاس، چرا که این زبان یکی از نام‌‌دار‌ترین زبان‌های است که مصرف انرژی و منابع را به بهترین حالت ممکن می‌توان در آن مدیریت کرد، از طرفی در صورت پیاده‌سازی نه چندان مطلوب کد‌ها، ممکن است نتیجهٔ عکس بدهد. در واقع معتقد است ممکن است کد‌نویسی بهینه‌ای صورت نگیرد و منجر به مصرف نسبتاً بالایی داشته باشد.

    وقتی ساتوشی بیت‌کوین را نوشت، او به‌طور ضروری پیش‌بینی نکرد که مسابقه‌ای که به وجود آمد باعث ساخت دستگاه‌های ASIC ماینینگ خواهد شد. در واقع، در صفحهٔ سفید اصلی بیت‌کوین که تنها 9 صفحه است، ساتوشی کلمه CPU را به مجموع 10 بار اشاره کرد. مصرف انرژی کنونی بیت‌کوین کمتر بود اگر ماینینگ به شکلی انجام می‌شد که ساتوشی پیش‌بینی کرده بود. حتی ساتوشی نیز از همان سرنوشتی که استرواستروپ هشدار داد: عدم کنترل بر نحوه استفاده از ابداع خود در آینده، مصون نبود.

    احتمالاً ساتوشی هم پیش‌بینی نکرده بود که بیت‌کوین در میان مجرمان نیز استفاده خواهد شد. اگرچه ممکن بوده باشد که در یک دوره زمانی بیت‌کوین محبوبیت زیادی در میان تجار مواد مخدر داشته باشد، اما مونرو به عنوان رمزارز انتخابی در میان بسیاری از گروه‌های جرمی ظاهر شده است.

    فعالیت‌های بشر که در مقیاس بزرگ بر محیط زیست تأثیر منفی می‌گذارند، زیاد است. بنابراین، هیچ توجیه منطقی برای اختصاص به‌طور خاص به ماینینگ بیت‌کوین وجود ندارد، به‌ویژه زمانی که مزیت مثبت آن به حداکثر است. اختصاص مصرف انرژی به ماینینگ رمزارز به‌منظور ایجاد و حفظ یک سیستم همتا به منظور تبادل مالی، یک کار کارآمد است چرا که دقیقاً همان چیزی است که برای حذف واسطه‌های غیرضروری و غیرتکنولوژیکی لازم است: واسطه‌هایی که روز آن‌ها نهایتاً فرا رسیده است.

    به طور کلی، ارزیابی یک زبان برنامه‌نویسی باید با توجه به نیازها و شرایط پروژه‌ها صورت گیرد. سی‌پلاس‌پلاس در بسیاری از مواقع یک انتخاب عالی است و اگرچه ممکن است برخی نقدهایی وجود داشته باشد، اما این نقدها به طور کلی به عنوان چالش‌ها و به چشم‌گیرترین قابلیت‌های این زبان می‌توانند مطرح شوند.

     

    نتیجهٔ نهایی
    زبان برنامه‌نویسی سی‌پلاس‌پلاس احتمالاً محبوب‌ترین زبان برنامه‌نویسی در دنیای توسعه نرم‌افزار است. توسعه بلاکچین نیز شامل کدنویسی است و برخی از بلاکچین‌ها مانند شبکه بیت‌کوین از سی‌پلاس‌پلاس به عنوان زبان برنامه‌نویسی خود استفاده می‌کنند. ساتوشی ناکاموتو، خالق بیت‌کوین، این زبان را به دلیل امنیت و قابلیت مدیریت منابع تراکنش‌ها و عملیات قراردادهای هوشمند انتخاب کرد. به علاوه، این زبان به توسعه‌دهندگان امکان ادغام وظایف موازی و غیرموازی را به صورت بی‌نقص فراهم می‌کند. مصرف بهینهٔ منابع و رعایت موضوع انرژی سبز مهم است؛ همچنین، این زبان به‌طور منظم به‌روزرسانی می‌شود و ابزارهای تجزیه و تحلیل و اشکال‌زدائی متنوعی دارد که همگی به بهبود عملکرد آن کمک می‌کنند. نگاه به بهترین مزایای زبان در بلاکچین، به همه اجازه می‌دهد که درک کنند چرا ساتوشی ناکاموتو این زبان را در ایجاد بلاکچین بیت‌کوین انتخاب کرد.

    ایجاد بلاک‌چین ناکاموتو یکی از پربارترین اختراعات فناوری مالی زمان ما را ایجاد کرد که شفافیت، تمرکززدایی و ماندگاری تراکنش ها و داده ها را تقویت کرد. ارز متمرکز بر بلاک‌چین نیز همچنان پر استفاده ترین، قابل اعتمادترین، ارز دیجیتال پرسود و چشم انداز سرمایه گذاری است و در پشت ساخت این فناوری غول زبان‌های برنامه‌نویسی آن را به بهترین نوع خود تبدیل و در همین راستا در مسیر توسعه و پیشرفت هدایت می‌کند.

  3. شرکت اینتل یک کیت توسعه نرم‌افزار آزمایشی کوانتومی با نام Quantum SDK را منتشر کرد!

     این کیت یک سری ابزار و روش‌های برنامه‌نویسی را در اختیار توسعه‌دهندگان قرار می‌دهد که امکان برنامه‌نویسی الگوریتم‌های کوانتومی را در یک شبیه‌سازی ممکن می‌کند. این کیت از زبان برنامه‌نویسی ++C و کامپایلر LLVM برای برنامه‌نویسی الگوریتم‌های کوانتومی استفاده می‌کند و به سادگی می‌تواند با برنامه‌های C و ++C و پایتون به کار برده شود. این کیت، به نوعی باعث بزرگ شدن جامعه‌ٔ توسعه‌دهندگانی می‌شود که در زمینه‌ٔ کامپیوترهای کوانتومی فعالیت می‌کنند.

     

    photo_2023-04-21_04-58-29.jpg

    این عکس نشان می‌دهد که شرکت اینتل، و افرادی که در آن کار می‌کنند، با استفاده از یک دستگاه پردازشی ۳۰۰ میلی‌متری، وافرین بر روی یک وافر کیوبیتی (بخشی از یک صفحه اتصال کوانتومی) سیلیسیوم بر روی یک ورقه کوچک انجام داده‌اند.

    نقل قول

    این نقل‌قول بیان می‌کند که کیت توسعه نرم‌افزاری کوانتومی اینتل، به برنامه‌نویسان کمک می‌کند تا برای کامپیوترهای کوانتومی گسترده مقیاس آینده آماده شوند. این کیت نه تنها به توسعه‌دهندگان کمک می‌کند تا در شبیه‌سازی الگوریتم‌های کوانتومی و برنامه‌ها مسلط شوند بلکه با ایجاد یک جامعه از توسعه‌دهندگان به پیشرفت صنعت کوانتومی کمک می‌کند که باعث تسریع در توسعه‌ی برنامه‌هایی می‌شود که آمادگی آن‌ها در هنگام قرار گرفتن سخت‌افزار کوانتومی اینتل را دارند.

    – آن ماتسورا، مدیر برنامه‌های کاربردی و معماری کوانتومی، آزمایشگاه‌های اینتل

    درباره‌ی Intel Quantum SDK 1.0: نسخه‌ٔ 1.0 این SDK، شامل یک رابط برنامه‌نویسی مبتنی بر سی‌پلاس‌پلاس است که به برنامه‌نویسان کلاسیکی، زبان برنامه‌نویسی که با آن آشنایی دارند، را ارائه می‌دهد و امکان همکاری بین آن‌ها و برنامه‌نویسان کوانتومی را فراهم می‌کند. این کیت نیز، یک محیط اجرایی کوانتومی بهینه‌سازی شده برای اجرای الگوریتم‌های کوانتومی-کلاسیکی هیبریدی دارد. توسعه‌دهندگان می‌توانند از دو محیط مختلف برای شبیه‌سازی کیوبیت‌ها استفاده کنند، یکی برای نمایش بیشتر تعدادی کیوبیت‌های عمومی و دیگری، برای شبیه‌سازی سخت‌افزار کیوبیتی اینتل. محیط اولیه، یک شبیه‌ساز  کیوبیت عمومی بسیار عالی با کد منبع باز به نام Intel® Quantum Simulator (IQS) می‌باشد که برای 32 کیوبیت در یک گره و بیش از 40 کیوبیت در چندین گره، توانایی دارد. محیط دوم نیز با شبیه‌سازی سخت‌افزار کیوبیتی اینتل، شبیه‌سازی کوچک مدل کیوبیت‌های گرداننده اسپین سیلیکونی اینتل را فراهم می‌کند. کیوبیت‌های اینتل، از تخصص شرکت در تولید ترانزیستور سیلیکونی برای ساخت کامپیوترهای کوانتومی مقیاس گسترده استفاده می‌کنند.

    photo_2023-04-21_04-58-20.jpg 

    تحقیقات کوانتومی اینتل از دستگاه‌های کیوبیتی تا معماری سخت‌افزار کلی، معماری نرم‌افزار و برنامه‌ها را پوشش می‌دهد. Intel Quantum SDK یک کامپیوتر کوانتومی کامل در شبیه‌سازی است که همچنین قادر به اتصال به سخت‌افزار کوانتومی اینتل، از جمله چیپ کنترل Horse Ridge II و چیپ کیوبیت گرداننده اسپین اینتل است که بزودی در اختیار عموم قرار خواهد گرفت.

    photo_2023-04-21_04-58-23.jpg

    کیت توسعه‌ٔ کوانتومی اینتل، به توسعه‌دهندگان این امکان را می‌دهد که انتخاب کنند کدام یک از دو محیط موردنیاز برای شبیه‌سازی کیوبیت‌ها استفاده شود:

    1. شبیه‌ساز بسیار عالی و با کد منبع باز کیوبیت عمومی، شبیه‌ساز کوانتومی اینتل (Intel Quantum Simulator)
    2. محیط هدف که سخت‌افزار کیوبیتی اینتل را شبیه‌سازی می‌کند و به شبیه‌سازی مدل کوچک کیوبیت‌های گرداننده اسپین سیلیکون اینتل امکان می‌دهد.

    photo_2023-04-21_04-58-26.jpg

    اعلام شده که شرکت اینتل، متعهد به پیشروی در حوزه‌ٔ کامپیوترهای کوانتومی است و از جمله اینترنت از همه جا به عنوان یک روش برای جذب جامعه‌ٔ توسعه‌دهندگان می‌باشد. کاربران بتا این کیت، در حال بررسی انواع موارد مثل دینامیک سیالات، فیزیک نجوم وطراحی مواد هستند.

    photo_2023-04-21_04-58-32.jpg

    تحقیقات کوانتومی اینتل از دستگاه‌های کیوبیتی تا معماری سخت‌افزار کلی، کنترل و معماری نرم‌افزار و برنامه‌ها را پوشش می‌دهد.

  4. یکی از مواردی که در مباحث شیء‌گرایی مهم هستن با عنوان اصول SOLID شناخته می‌شه که شاید خیلی‌ها شنیده باشند.

    واژهٔ SOLID برگرفته شده از پنج اصلِ زیر است:

    1. S - Single-responsiblity Principle
    2. O - Open-closed Principle
    3. L - Liskov Substitution Principle
    4. I - Interface Segregation Principle
    5. D - Dependency Inversion Principle

    68747470733a2f2f6d69726f2e6d656469756d2e636f6d2f6d61782f313139312f312a4f7a774152627648556731526c5a374c59794c4372672e706e67.png

     

    برای پیاده‌سازی SOLID در C++20، می‌توانید از ویژگی‌های زبان استفاده کنید. برای مثال:

    •  برای پیاده‌سازی SRP، می‌توانید از کلاس‌های ساختاری (Structs) و کلاس‌ها و متد‌ها که فقط یک وظیفه دارند، استفاده کنید.
    •  برای پیاده‌سازی OCP، می‌توانید از الگوی Visitor و Strategy استفاده کنید. این باعث می‌شود که کلاس‌های شما قابلیت بسته‌بودن (Close) و در عین حال قابلیت گسترش ‌(Open) را داشته باشند.
    •  برای پیاده‌سازی LSP، می‌توانید از وراثت، کلاس‌های پایه (Base classes) و کلاس‌های مشتق (Derived classes) استفاده کنید و مطمئن شوید که اصول وراثت رعایت شده است.
    •  برای پیاده‌سازی ISP، می‌توانید از الگوی Interface استفاده کنید که به شما امکان می‌دهد که کلاس‌ها فقط به آن قسمت‌هایی از یک Interface نیاز دارند که به آن‌ها لازم است و از بقیه صرف نظر کنند.
    •  برای پیاده‌سازی DIP، می‌توانید از Dependency Injection استفاده کنید که به شما این امکان را می‌دهد که از تمام وابستگی‌های بین کلاس‌ها جدا شده و به‌صورت جداگانه به هم پیوندید، به‌طوری‌که تغییر در یک کلاس اثرات اصلی بر سایر کلاس‌ها نداشته باشد.

    اصلِ اول مربوط به اصل Single-Responsibility Principle یا همان SRP است. این اصل مشخص می‌کند که کلاس‌های شما باید هر کدامشان فقط و فقط باید یک وظیفهٔ مشخص داشته باشند و نه بیشتر!

     

    برای پیاده‌سازی SRP

    بنابراین، اصلِ SRP در شیء‌گرایی به معنی این است که هر کلاس و متد باید فقط یک مسئولیت یا وظیفه را برعهده داشته باشد. این یعنی که هر کلاس فقط باید یک مورد از نرم‌افزار را انجام دهد و تغییر در آن، صرفا برای اعمال تغییرات در آن مورد خاص یا در راستای بهبود مسئولیتش باشد.

    با رعایت اصل SRP، کدها به راحتی قابل نگهداری، توسعه و آزمایش خواهند بود؛ زیرا هر قطعه از کد فقط برای انجام کار خاص خود طراحی شده است و هیچ گونه وظیفه‌ای به کلاس اضافه نشده است. این نه تنها باعث بهبود خوانایی و قابلیتِ پیش‌بینیِ کد می‌شود، بلکه باعث کاهش پیچیدگی و احتمال خطا نیز می‌شود.

    برای پیاده‌سازی SRP در سی‌پلاس‌پلاس مثالی خواهم زد؛ ابتدا باید کلاس را به شکلی طراحی کنید که فقط یک مسئولیت را در بر داشته باشد. به عنوان مثال، فرض کنید یک کلاس برای محاسبه‌ٔ مساحت یک شکل هندسی طراحی می‌کنید. با توجه به SRP، این کلاس فقط باید مسئول محاسبه‌ٔ مساحت باشد و هیچ وظیفه‌ای دیگر را نباید برعهده بگیرد.

    class Shape {
    public:
        virtual double area() const = 0;
    };
    
    class Rectangle : public Shape {
    public:
        Rectangle(double h, double w) : height(h), width(w) {}
        double area() const override {
            return height * width;
        }
    private:
        double height;
        double width;
    };
    
    class Circle : public Shape {
    public:
        Circle(double r) : radius(r) {}
        double area() const override {
            return 3.1415 * radius * radius;
        }
    private:
        double radius;
    };

    در این مثال، کلاس Shape یک مسئولیت واحد دارد که محاسبه‌ٔ مساحت شکل هندسی است. همینطور کلاس‌های Rectangle و Circle نیز فقط مسئول محاسبه‌ٔ مساحت هر یک از شکل‌های هندسی خود هستند.

    به این ترتیب، هر یک از این کلاس‌ها فقط یک مسئولیت دارند و تغییراتی که در آینده رخ می‌دهد، مربوط به تابعی است که این مسئولیت را پوشش می‌دهد و هرگونه تغییرات دیگری نباید شامل کلاس شود.

     

    برای پیاده‌سازی OCP

    اصلِ Open/Closed Principle (اصل OCP) در شیء‌گرایی به معنی ایجاد کلاس‌ها به گونه‌ای است که برای اضافه کردن ویژگی جدید به یک برنامه، نیاز به تغییر کد قبلی نباشد. به عبارت دیگر، کلاس‌ها باید برای توسعه باز باشند (Open)، اما برای تغییر نباشند (Closed). برای پیاده‌سازی OCP، می‌توانید از ارث‌بری، پلی‌مورفیسم، استفاده از ابستراکت کلاس‌ها (کلاس‌های انتزاعی)، الگوی تزریق وابستگی و ... استفاده کنید. این اصل بهبود پذیری (extensibility) و بهره‌وری کد را بهبود می‌بخشد. همچنین برای پیاده‌سازی OCP، می‌توانید از الگوی Visitor و Strategy استفاده کنید. این باعث می‌شود که کلاس‌های شما قابلیت بسته‌بودن (Close) و در عین حال قابلیت گسترش ‌(Open) را داشته باشند.

    به عنوان مثال، فرض کنید یک برنامه داریم که می‌تواند اشکال هندسی مختلف را رسم کند. برای پیاده‌سازی OCP، می‌توانید کلاس اشکال هندسی را به گونه‌ای طراحی کنید که بتوانید به راحتی از آن‌ها ارث‌بری کنید و اشکال جدیدی را به سیستم اضافه کنید بدون ایجاد تغییرات بیشتر در کد قبلی. به عنوان مثال، اینجا یک کد ساده برای این کار نوشته شده است:

    #include <iostream>
    #include <vector>
    
    class Shape {
    public:
        virtual void draw() = 0;
    };
    
    class Rectangle : public Shape {
    public:
        void draw() override {
            std::cout << "Drawing a rectangle\n";
        }
    };
    
    class Circle : public Shape {
    public:
        void draw() override {
            std::cout << "Drawing a circle\n";
        }
    };
    
    class GraphicEditor {
    public:
        void drawAllShapes(std::vector<Shape*> shapes) {
            for (auto shape : shapes) {
                shape->draw();
            }
        }
    };
    
    int main() {
        GraphicEditor editor;
        std::vector<Shape*> shapes = { new Rectangle(), new Circle() };
        editor.drawAllShapes(shapes);
        for (auto shape : shapes) {
            delete shape;
        }
        return 0;
    }
    

    در این مثال، کلاس Shape در واقع یک واسط برای هر یک از شکل‌های هندسی است. کلاس Rectangle و کلاس Circle از کلاس Shape ارث‌بری کرده‌اند و تابع draw آن را پیاده‌سازی کرده‌اند. به این ترتیب، می‌توانید در آینده اشکال هندسی جدیدی را به کد اضافه کنید بدون نیاز به تغییر کد اصلی.

     

    برای پیاده‌سازی LSP

    اصل LSP به معنی اصل جایگزینی قابل توجه لیسکوف (Liskov Substitution Principle) در شیء‌گرایی به این مفهوم است که باید بتوان اشیاء موروثی از یک کلاس را با اشیاء کلاس والد جایگزین کرد. به عبارت دیگر، هر جایگزین یا زیرکلاس باید بتواند عملکرد و ویژگی‌های کلاس والد را حفظ کند و بدون هیچ تغییری، به جای کلاس والد استفاده شود. در واقع، هدف این اصل این است که به جای ایجاد جایگزین‌هایی که منجر به عملکرد غیرقابل پیش‌بینی می‌شوند، جایگزین‌هایی باشند که با انجام کارهایی مانند جایگزینی هنوز هم به نحو شایسته عمل کنند.

    فرض کنید که گربه و سگ، از یک کلاس حیوان وارثی هستند. برای همه‌ٔ حیوانات منطقی است که بتوانند صدای حیوان را تولید کنند. در اینجا با توجه به اصل LSP، باید بتوانیم به جای یک شیء گربه، یک شیء سگ یا شیء کلاس والدِ حیوان را به عنوان جایگزین استفاده کنیم و همچنین از آن‌ها بخواهیم که قابلیت تولید صدا را داشته باشند. به عبارت دیگر، صدای گربه و صدای سگ برای ما دقیقاً در یک رده‌بندی هستند و در همان حیطه معنایی قرار دارند، بنابراین باید بتوانیم هر یک از آن‌ها را به عنوان جایگزین برای دیگری استفاده کنیم.

    یک مثال ساده از اصل LSP در C++20، می‌تواند مربوط به کلاس‌های Shape و Rectangle باشد. فرض کنید کلاس Rectangle از کلاس Shape و از آن ارث‌بری کرده باشد. برای رعایت اصل LSP، کلاس Rectangle باید تمام روش‌های کلاس Shape را پیاده‌سازی کند، به گونه‌ای که در هر جایی که در کد از کلاس Shape استفاده می‌شود، می‌توانیم جایگزین آن را با کلاس Rectangle استفاده کنیم.

    کلاس Shape می‌تواند به صورت زیر باشد:

    class Shape {
    public:
        virtual double area() = 0;
        virtual double perimeter() = 0;
    };

    و کلاس Rectangle از شکل یک مستطیل با طول و عرض دلخواه پیاده‌سازی شده است:

    class Rectangle : public Shape {
    private:
        double length;
        double width;
    public:
        Rectangle(double l, double w) : length(l), width(w) {}
        double area() override {
            return length * width;
        }
        double perimeter() override {
            return 2 * (length + width);
        }
    };

    حال، با استفاده از این کلاس‌ها، می‌توانیم مستطیلی با طول و عرض دلخواه ایجاد کنیم و روش‌های کلاس Shape را روی آن صدا بزنیم:

    Shape* shapePtr = new Rectangle(4, 6);
    double area = shapePtr->area();
    double perimeter = shapePtr->perimeter();

    در اینجا، کلاس Rectangle با کلاس Shape جایگزین شده و اصل LSP رعایت شده است، به این معنی که هر جایی که از کلاس Shape استفاده شده، می‌توانیم جایگزین آن را با کلاس Rectangle استفاده کنیم، بدون هیچ تغییری در کد قبلی.

     

    برای پیاده‌سازی ISP

    اصل ISP به معنی اصل جداسازی رابط (Interface Segregation Principle) در شیء‌گرایی به این مفهوم است که باید رابط‌ها را به گونه‌ای طراحی کرد که اشیاء فقط به آنچه برایشان لازم است دسترسی داشته باشند و به سایر اجزای رابط دسترسی نداشته باشند. به عبارت دیگر، باید یک رابط یکتا و بزرگ به چندین رابط کوچک و مجزا تفکیک شود تا برای هر کلاس، فقط تعداد کم و لازمی از ویژگی‌ها و روش‌ها در دسترس باشد. 

    برای پیاده‌سازی ISP، می‌توانید از الگوهای طراحی مانند واسط‌ها (Interfaces) و کلاس‌های واسط (Abstract Classes) استفاده کنید. با استفاده از این الگوها، می‌توانید پیچیدگی‌های شناور در برنامه خود را کاهش داده و تغییرات را در کد خود به راحتی انجام دهید.

    در واقع، هدف این اصل این است که کلاینت‌ها باید بتوانند با استفاده از رابط‌های ساده تر و متعارف، با سیستم تعامل داشته باشند. این روش منجر به افزایش قابلیت توسعه و خودکارسازی کد، بهره‌وری بالا و حتی صرفه‌جویی در زمان و هزینه خواهد شد. برای مثال نمونهٔ زیر به عنوان بخشی از پردازش تصویر می‌باشد:

    ابتدا واسط ImageTransformer را تعریف می‌کنیم که حاوی متدهای تبدیل تصویر به سیاه و سفید و برعکس آن است:

    class ImageTransformer {
    public:
       virtual void transformToBlackAndWhite() = 0;
       virtual void transformToColor() = 0;
    };

    سپس دو کلاس ImageToBlackAndWhiteTransformer و ImageToColorTransformer را برای پیاده‌سازی واسط ImageTransformer تعریف می‌کنیم:

    class ImageToBlackAndWhiteTransformer: public ImageTransformer {
    public:
        void transformToBlackAndWhite() override {
            // Implement the transformation to black and white
        }
    };
    
    class ImageToColorTransformer: public ImageTransformer {
    public:
        void transformToColor() override {
            // Implement the transformation to color
        }
    };

    حال می‌توانیم از هر یک از کلاس‌های ImageToBlackAndWhiteTransformer و ImageToColorTransformer برای پردازش تصویر استفاده کنیم.

    در نهایت، به عنوان مثالی از استفاده از متد‌های رابط ImageTransformer، کد زیر را در نظر بگیرید:

    void processImage(ImageTransformer& transformer) {
        transformer.transformToBlackAndWhite();
        transformer.transformToColor();
    }

    در این کد، با گرفتن یک شیء از کلاسی که از واسط ImageTransformer ارث‌بری کرده است، می‌توانیم تصویر را به سیاه و سفید و برعکس آن تبدیل کنیم که بر اساس اصل ISP طراحی شده‌است.

    برای پیاده‌سازی اصل ISP در C++20 به‌طور کلی، می‌توان از این ویژگی بهره برد که به نام concepts شناخته می‌شود. این ویژگی به برنامه نویسان امکان می‌دهد که شرایط و محدودیت‌هایی را برای قالب‌ها، ورودی‌ها و خروجی‌ها تعریف کنند و باعث شود که کد بهتری با پایداری بیشتری نوشته شود.

    برای استفاده از این ویژگی در پیاده‌سازی اصل ISP در C++20، می‌توانید از مفهومی استفاده کنید که برای اطمینان از قابلیت اجرا و خطاهای برنامه سازی موجود است. برای مثال، در کد زیر، الگوهای واسط که برای پردازش تصویر استفاده می‌شوند، با نام‌های ImageTransformer و GrayscaleTransformer (با استفاده از template) تعریف شده‌اند. هر کدام از این الگوهای واسط، تعدادی عملیات مشخص شده را تعریف می کنند. سپس با استفاده از این الگوها، کلاس ImageProcessor (نیز با استفاده از template) برای پردازش تصویر طراحی شده است.

    template<typename T>
    concept ImageTransformer = requires(T t, cv::Mat image) {
        { t.transform_to_grayscale(image) } -> cv::Mat;
        { t.transform_to_rgb(image) } -> cv::Mat;
    };
    
    template<typename T>
    concept GrayscaleTransformer = requires(T t, cv::Mat image) {
        { t.transform_to_grayscale(image) } -> cv::Mat;
    };
    
    template <typename T>
    class ImageProcessor {
    public:
        ImageProcessor(T* transformerPtr) : transformerPtr_{ transformerPtr } { }
        
        cv::Mat transform_to_grayscale(cv::Mat image) {
            return transformerPtr_->transform_to_grayscale(image);
        }
        
        cv::Mat transform_to_rgb(cv::Mat image) {
            return transformerPtr_->transform_to_rgb(image);
        }
        
    private:
        T* transformerPtr_;
    };

    همچنین، می‌توانید کلاس‌های مربوط به پردازش تصویر یعنی GrayscaleImageTransformer و RGBImageTransformer را به این الگوها منطبق کنید. در کد زیر، چک کردن اینکه یک کلاس منطبق بر پیشنیازهای ImageTransformer است یا نه، انجام شده است.

    class GrayscaleImageTransformer : public GrayscaleTransformer {
    public:
        cv::Mat transform_to_grayscale(cv::Mat image) override {
            cv::Mat grayscaleImage;
            cv::cvtColor(image, grayscaleImage, cv::COLOR_BGR2GRAY);
            return grayscaleImage;
        }
    };
    
    class RGBImageTransformer : public ImageTransformer {
    public:
        cv::Mat transform_to_grayscale(cv::Mat image) override {
            cv::Mat grayscaleImage;
            cv::cvtColor(image, grayscaleImage, cv::COLOR_BGR2GRAY);
            return grayscaleImage;
        }
        
        cv::Mat transform_to_rgb(cv::Mat image) override {
            cv::Mat rgbImage;
            cv::cvtColor(image, rgbImage, cv::COLOR_GRAY2BGR);
            return rgbImage;
        }
    };
    
    int main() {
        GrayscaleImageTransformer grayscaleTransformer;
        RGBImageTransformer rgbTransformer;
        
        ImageProcessor grayscaleProcessor{ &grayscaleTransformer };
    
        cv::Mat image; 
        image = cv::imread("image.jpg");
    
        auto grayscaleResult = grayscaleProcessor.transform_to_grayscale(image);
        
        ImageProcessor rgbProcessor{ &rgbTransformer };
        auto rgbResult = rgbProcessor.transform_to_rgb(grayscaleResult);
    
        cv::imwrite("grey.jpg", grayscaleResult);
        cv::imwrite("rgb.jpg", rgbResult);
    
        return 0;
    }

     

    برای پیاده‌سازی DIP

    DIP یا Dependency Inversion Principle (اصل وابستگی معکوس) یکی از اصول SOLID در شیء‌گرایی است که به مفهوم وابستگی به جایی یا Inversion of Control (IOC) هم معروف است. اصل DIP بیان می‌کند که برنامه باید به گونه‌ای طراحی شود که وابستگی به جزئیات پیاده‌سازی برنامه کاهش یابد و به جای آن، برنامه باید بر اساس واسط‌ها (interface) ارتباط برقرار کند، به گونه‌ای که خود وابستگی به جزئیات پیاده‌سازی به صورت بالادستی بر اساس واسط‌ها مدیریت شود.

    با استفاده از اصل DIP، کد قابلیت بازگشت و تغییر بهتر را دارد. این بدان معناست که تغییر در پیاده‌سازی یک کد، تنها روی کد فعلی تأثیر نمی‌گذارد و به خاطر استفاده از واسط‌ها، به صورت گسترده‌تر در برنامه تأثیر می‌گذارد. با رعایت اصل DIP، کدها با استفاده از واسط‌ها باید طراحی شوند و نباید به کد پیاده‌سازی جزئیات برچسب تمایل یا وابستگی داشته باشند. به عبارت دیگر، برنامه باید بر اساس قرارداد کار کند نه کد پیاده‌سازی.

    یک مثال ساده از پیاده‌سازی DIP در C++ به صورت زیر است:

    فرض کنید یک برنامه ساده را برای محاسبه جدول ضرب در نظر بگیرید. برای پیاده‌سازی این برنامه، یک کلاس MatrixCalculator وجود دارد که دارای دو متد است که برای محاسبه جدول ضرب به کار می‌روند: multiply و print.

    ابتدا یک واسط مشترک بین MatrixCalculator و کلاس‌های مختلف جدول تعریف می‌کنیم:

    class IMatrix {
    public:
        virtual void multiply() = 0;
        virtual void print() = 0;
    };

    سپس دو کلاس Matrix2x2 و Matrix3x3 را برای پیاده‌سازی واسط IMatrix تعریف می‌کنیم:

    class Matrix2x2 : public IMatrix {
    public:
        void multiply() {
            // implementation for 2x2 matrix multiplication
        }
    
        void print() {
            // implementation for 2x2 matrix printing
        }
    };
    
    class Matrix3x3 : public IMatrix {
    public:
        void multiply() {
            // implementation for 3x3 matrix multiplication
        }
    
        void print() {
            // implementation for 3x3 matrix printing
        }
    };

    حالا کلاس MatrixCalculator را به گونه‌ای تغییر می‌دهیم که به جای استفاده از پیاده‌سازی خاص هر کلاس، از واسط IMatrix استفاده کند:

    class MatrixCalculator {
    private:
        IMatrix* matrix;
    public:
        MatrixCalculator(IMatrix* m) : matrix(m) {}
    
        void multiply() {
            matrix->multiply();
        }
    
        void print() {
            matrix->print();
        }
    };

    بنابراین حالا می‌توانیم کلاس MatrixCalculator را به صورت زیر استفاده کنیم:

    IMatrix* m2x2 = new Matrix2x2();
    MatrixCalculator calculator2x2(m2x2);
    calculator2x2.multiply();
    calculator2x2.print();
    
    IMatrix* m3x3 = new Matrix3x3();
    MatrixCalculator calculator3x3(m3x3);
    calculator3x3.multiply();
    calculator3x3.print();

    با این رویکرد، هر زمان که یک کلاس جدید با پیاده‌سازی واسط IMatrix ایجاد شود، می‌توانیم آن را به کلاس MatrixCalculator اضافه کرده و آن را بدون تغییر در کد MatrixCalculator استفاده کنیم. همچنین وابستگی MatrixCalculator به کلاس‌های Matrix2x2 و Matrix3x3 برای انجام کارش کاهش یافته است.

    در C++20 می‌توان از ویژگی concepts برای پیاده‌سازی DIP استفاده کرد. در اینجا مثال ساده‌ای از پیاده‌سازی DIP با ویژگی concepts در C++20 آورده شده است:

    #include <iostream>
    #include <concepts>
    
    template <typename T>
    concept Comparable = requires(T a, T b) {
        { a == b } -> std::convertible_to<bool>;
        { a != b } -> std::convertible_to<bool>;
    };
    
    template <typename T>
    class Calculator {
    public:
        Calculator(T num1, T num2) : num1_(num1), num2_(num2) {}
    
        T add() requires Comparable<T> {
            return num1_ + num2_;
        }
        
    private:
        T num1_;
        T num2_;
    };
    
    int main() {
        Calculator<int> intCalc(5, 10);
        std::cout << intCalc.add() << std::endl;
    
        Calculator<float> floatCalc(5.5, 10.5);
        std::cout << floatCalc.add() << std::endl;
    
        // Calculator<std::string> strCalc("hello", "world");   // Compile-time error
        return 0;
    }

    در این مثال، ما از ویژگی concepts برای تعریف واسط Comparable استفاده کرده‌ایم. همچنین، کلاس Calculator از واسط Comparable به عنوان یک شرط برای تعریف تابع add استفاده شده است. با این رویکرد، ما به سادگی می‌توانیم به جای وابستگی به یک نوع دقیق، وابستگی به یک واسط را ایجاد کنیم.

  5. سلام و درود،

    این اواخر راجع به مشورت و راهنمایی‌ها خیلی ساده به قضیه نگاه می‌شه، همه فکر کردن کشکه و فقط با دونستن JS یا QML می‌شه محصول ساخت. البته این مثال JS و QML یک مثال هست و این مسئله در همهٔ ابزار‌ها و حول محور حوزهٔ کامپیوتر و نرم‌افزار به چشم می‌خوره، هرچند روی داستان ساده هست اما حتی پشت این کار‌های ساده کلی زمان باید صرف بشه. همین گرفتن یک دادهٔ ساده از سمت سرور و تجزیه کردنش سمت JS نیاز به یک دانش خوب در مورد معماری Api‌داره، نیاز به آگاهی از استاندارد‌های Http داره، نیاز به تخصص کافی در ریز به ریز مسائل داره، نیاز به آگاهی لازم در مورد شبکه و نحوهٔ مدیریتش داره، نیاز به درک خوب راجع به کلاس‌های شبکه و نحوهٔ مدیریت بسته‌ها داره و صد‌ها جور مسئلهٔ دیگه.

    road-sign-01.png

    یا راهنمایی نکنیم یا می‌کنیم همه چیز رو ساده نشون ندیم!
    به خصوص برای کسایی که سال‌ها یه چیز دیگه خوندن و الآن قراره وارد این حوزه بشن.
    قشنگ واقعیت رو باید به نمایش گذاشت، و اگرنه به اشتراک گذاری چهارتا UI خفن که بگین با QML هم میشه کاری نداره، سه سوته می‌شه این‌ها رو طراحی کرد.

    اگر کسی اطلاعات کافی و پایهٔ تخصصی نداشته باشه و همینطور متکی به یک ابزار یا زبان پیش بره چه اتفاق می‌افته؟ از نظر من قطعاً بهتون از نظر تجربی آسیب میزنه، ساخت یک محصول واقعاً به این سادگی‌ها نیست که تو گروه‌های تلگرامی داریم راجع بهش صحبت می‌کنیم! قضیه خیلی پیچیده‌تر از این‌هاست. فراموش نکن در این حوزه اگه یک کار ساده رو سریع انجام میدیم یا به نتیجه می‌رسونیم دلیلش به خاطر سال‌ها زمان و تلاشه، امکان نداره کسی حتی با ۲..۳ سال تجربه یک کار رو سریع بتونه صفر تا صد انجام بده و مشکلی نداشته باشه یا نتیجهٔ اون در سطح یک استاندارد معتبر باشه.

    ساخت محصول اصول داره که اولین مرحلش شفاف‌سازی و نقشهٔ توسعه و ایده‌پردازی درسته، نباید مثل بعضی از مشتری‌ها باشه که پشت تلفن زنگ می‌زنن می‌گن یه سایت می‌خوایم یا یه اپلیکیشن چند می‌گیری و بعدش شروع کنن به چک و چونه زدن و شما هم کیف کنی بگی که آره دیگه مشتری دارم!

    شما تا زمانی که جزء به جزء محصول رو آگاه نباشید، یعنی تا زمانی که دقیق متوجه نشید نیاز چی هست و روش حلش رو متوجه نباشید منطقی نیست که واردش بشید. چون همین مرحلهٔ نیاز‌سنجی به قدری مهمه که فرآیند مسیر و نقشهٔ توسعهٔ یک محصول رو نشونتون میده و اگه درست تشخیص ندین و ابزار‌ها و راه‌کار‌ها رو درست انتخاب نکنید بی برو برگرد با مشکل مواجه می‌شید.

    مشکلاتش می‌تونه به این صورت باشه:

    - سردرگمی
    - عدم توانایی کالبد‌شکافی مسئله
    - عدم توانایی حل مسئله
    - عدم توانایی انتخاب یک روش یا ابزار صحیح و مناسب
    - عدم تعامل شما با مشتری
    - عدم رضایت شما از حق‌الزحمه
    - عدم رضایت مشتری از نتیجهٔ کار
    - عدم توانایی در پاسخ‌دهی به اعضا و شرکای کلیدی دیگه در محصولات تجاری و بزرگ!
    - و هزاران مسئلهٔ دیگه که همشون نتیجهٔ تشخیص نا درسته.
    - در کنارش مهمترین خاصیتی که پیدا می‌کنه این خواهد بود در اوج نادانی احساس خواهد کرد که همه چیز دان هست! به قولی همه چیز گیگ!

    از نظر من حداقل مواردی که (به طور خیلی خیلی خلاصه و محدود) نیاز هست تا یک متخصص بتونه پاسخ‌گوی‌ تصمیم‌گیری نقشهٔ توسعهٔ یک محصول برای مشتری در ابعاد مختلف و سطوح متفاوت از حوزه‌های موجود در قالب اصولی باشه به صورت زیر هستند:

    ۱- آشنا مبانی کامپیوتر که امر طبیعیه (شامل درک و فهم مسائل و نحوهٔ حلشون متناسب با پلتفرم اجرایی محصول)
    ۲- آشنا به ساختار نوع محصول استاندارد در یک حوزه مثل: وب، آی‌او‌اس، اندروید یا دسکتاپ‌های مختلف مثل لینوکس، مک و ویندوز، اینترنت اشیاء و دیگر موارد.
    ۳- آشنا به فلسفهٔ بک‌اند و فرانت‌اند یا ترکیبی از این دو به همراه ابزار‌های مناسب.
    ۴- آشنا به اصول طراحی UI/UX به عنوان یک نیاز و یک فاکتور مهم در ساخت محصولی که وابسته به عملکرد کاربر داره و در حوزهٔ فرانت‌اند مهم و کاربردی هست.
    ۵- آشنا به اصول SOLID و امثالش مهم هستند.
    ۶- آشنا اصول برنامه‌ریزی ساخت بانک اطلاعاتی، اینکه از چه بانک اطلاعاتی‌ای استفاده کنی و چرا؟
    ۷- آشنا به ارتباطات داده‌ای، جداول و ارتباط بین فیلد‌ها، جدوال و روش‌های درست تبادل اطلاعات مابینی داده‌ها.
    ۸- آشنا و تسلط کافی به یک محیط توسعه و ادغام ابزار‌ها و محیط طراحی برای هدف.
    ۹- آشنا به معماری ساختار و رابط‌های برنامه‌نویسی (Api)
    ۱۰- آشنا به استاندارد‌های Http، درک و مدیریت درخواست، پاسخ‌ها و ...
    ۱۱- آشنا به الگو‌های طراحی برنامه‌نویسی (DP)
    ۱۲- آشنا به روش‌های نگه‌داری و آزمایش نرم‌افزار و کد‌ها به خصوص درک مبحث Fault tolerance.
    ۱۳- آشنا به روش‌های اطمینان‌سازی و ایمن‌سازی پردازش‌های داخلی نرم‌افزار برای جلوگیری یا دشوار سازی نفوز و خراب‌کاری
    ۱۴- آشنا به روش‌ها و معماری‌های احراز هویت و نحوهٔ ادغامش با نرم‌افزار مثل:JWT, OAuth, AWS و غیره...
    ۱۵- آشنا به نوع پارادایم‌های زبان برنامه‌نویسی، در قالب‌های  (دستوری) Imperative و  (اعلانی) Declarative مثل OOP، functional و دیگر موارد.
    ۱۶- آشنا به سبک معماری نرم‌افزاری (Microservice یا مثلاً Monolith) مزایا و معایبشون.
    ۱۷- آشنا به سبک معماری طراحی مانند MVC در طراحی بدنهٔ محصول.
    ۱۸- آشنا به سبک و الگو‌های طراحی ساختاری در بک‌اند مانند Builder، Abstract، Factory و غیره.
    ۱۹- آشنا به ساختار یک زبان (در صورتی که می‌خواین جوابگوی مسائلِ پیش آمده باشید) کالبد‌شکافی زیر‌پوستی و عمیق یک زبان مهمه.
    ۲۰- آشنا و درک کامپایلر‌ها و مفسر‌ها، تفاوت‌ها و شیوه‌های عملکردیشون نسبت به کد‌های بهینه شده و عادی.
    ۲۱- آشنا و درک مدل‌های مختلفی از سیستم‌های توزیع شده مثل IaaS، PaaS، SaaS یا FaaS.
    ۲۲- آشنا به ابزار‌های ساخت و فرآیند کاری اون‌ها مثل CMake، NMake، QMake و غیره.
    ۲۳- آشنا به روش‌های مدیریت وابستگی‌های نرم‌افزار و ابزار‌های لازم برای بسته‌بندی بهتر خروجی.
    ۲۴- آشنا به روش‌های کد‌نویسی قابل آزمایش (Unit Test) و استفاده از ابزار‌هایی مثل CTest, GTest, Catch2 و غیره.
    ۲۵- آشنا به توسعهٔ آزمون محور (Test Driven- Development)
    ۲۶- آشنا به گام‌ها و شرایط نسخه‌نگاری و مراحل توسعهٔ نرم‌افزار (SDP)
    ۲۷- آشنا به روش‌های امنیت در کد و توسعه به شیوه‌های بررسی از طریق Fuzz-Test، Sanitizer، آنالیزر‌های پویا و ایستا و غیره...
    ۲۸-آشنا به قوائد طراحی بر پایهٔ خدمات مبتدی بر معماری ابری برای خدمات پیامی، وب‌سرویس‌ها، پردازش و غیره.
    ۲۹- در سطوح وب آشنا به مکانیزم شاخص بندی، فاکتور‌های SEO و شیوه‌‌های درست بهبود صفحات وب.
    ۳۰- آشنا به روش‌های به کار گیری و پیاده‌سازی ثبت کننده‌ٔ وقایع در دل محصول و روش‌های بازخورد برای توسعهٔ بهتر به همراه مانیتورینگ، نظارت و تریسینگ.
    ۳۱- در شرایط لزوم آشنا به نحوهٔ به کار گیری و دلیل استفاده از فناوری‌هایی مثل Redis، Memcached و غیره.
    ۳۲- آشنا و درک صحیح از مفاهیم هم‌زمانی (Concurrency) و روش‌های به کار گیری آن نسبت به زبان برنامه‌نویسی و شرایط مناسب استفاده.
    ۳۳- آشنا به سبک و قوائد و ساختار زبان‌های برنامه‌نویسی و فرآیند ساخت و ترجمه.
    ۳۴- و تا صد‌ها گزینهٔ دیگه می‌تونم لیست کنم اینجا که اگه انتخابتون زبان‌های نزدیک به سیستم باشه این داستان در ادامهٔ این توضیحات سر به فلک می‌کشه نمونش کامپایلر‌ها خودشون شونصد جور مباحث دارند، پلتفرم‌ها ومعماری‌های پردازنده‌ای هم در این زبان‌ها مهمن و شما حتی تا عمق سیستم‌عامل و رابط‌های اون‌ها و نحوهٔ رفتارشون باید اطلاعات کافی داشته باشید که هر کدوم به نوبهٔ خودشون هزاران صفحه می‌شه راجع بهشون کتاب معرفی کرد.

    این لیست چیزی بود که به زبان بسیار بسیار ساده شده و خیلی خلاصه به ذهنم رسید تا بدانید همچین هم الکی نیست ای عزیزانی که فتوا‌های صد من یه غاز میدین و این مسائل رو حل شده می‌دونید! 

    در ادامه اصل ماجرا خیلی فراتر از این‌ها هم هست که بخوای حساب کتاب کنی می‌بینی باید هفت خان رستم رو فتح کنی تا در تمامی سطوح پاسخگو باشی، این امر شدنی هست اما زمانی که شما محدود به یک موضوع باشید قطعاً درک همهٔ مسائل محدود و ناتوان در اجرای آن خواهید شد.

    * وقتی می‌گم آشنا قطعاً در حد حروف الفبا کافی نیست، باید در حد نیاز تسلط و درک کافی ازشون وجود داشته باشه.
    * همهٔ این‌ها رو باید در کمترین زمان ممکن نسبت به یک مشتری، محصول و نیاز تشخیص بدین و انتخاب کنید، به این کار می‌گن ارزیابی محصول بر اساس دانسته‌های فنی که تماماً متکی بر دانش و تجربهٔ شماست. (کارشناسی پروژه دقیقاً همین موضوع است).
    * برای بهتر شدن و حرفه‌ای تر شدن هم باید فراتر از این‌ها پیش برید و در قالب «مثلث دانش» بهبودش بدهید.
    * محصولات معتبر جهانی حاصلِ چنین نقشه‌های پیش‌بردی هستند و اصول تخصصی و مهندسی رو رعایت می‌کنن تا به یک درجهٔ کیفی موفق و زبان زد می‌رسند. شاید این مسائل از نظر یک برنامه‌نویس ساده و نه چندان با تجربه مهم نباشه، اما در سطح کیفی یک محصول نرم‌افزاری همهٔ این مسائل مهم تلقی می‌شوند.

    برای همین می‌گم گولِ توصیه‌های ساده و ظاهر چهارتا برنامه یا کیوت، دات‌نت و امثال این ابزار‌ها رو نخورید، پشت همهٔ نیاز‌های یک محصول به فاکتور‌های بسیاری باید توجه کنید. فردا بخواهید بدون آگاهی در این مسائل وارد پروژه‌هایی بشید که به ظاهر ساده هستند یا باید دست به گریبان دیگران باشید و توی گروه‌ها مدام سوأل پرسی کنید و یا باید بیخیال آن شوید؛ چون به هیچ یک از این فاکتور‌های مورد نیاز توسعه توجه نکردین! پس این اصول رو به عنوان سر نخ مطالعه کنید تا بخش بزرگی از سرگردانی‌های شما حل شود.

    این مواردی که این جا اشاره کردم، همونطور که گفتم بخش بسیار کوچکی از دنیای نیازمندی‌های ساخت و ساز و طراحی یک محصول واقعی در پیرامون نرم‌افزار و کامپیوتر هست، اما یک دل‌گرمی بدم به کسایی که با خودشون فکر می‌کنند چنین مسیر یا نقشه‌ای از راه که قراره پیش بگیرند سخته و همهٔ ماجرا این نیست (جزئیات رو در کتاب‌ها، موقعیت و فرصت‌های شغلی، شکست‌ها، موفقیت‌ها و آزمون و خطاها یاد خواهند گرفت) و نتیجهٔ اون می‌تونه مطابق همین حکایت زیر باشه:

    نقل قول

    حکایت برنامه‌نویسان، ابزار‌ها، تجربه و تخصصی که در بازار بی ارتباط با آن نیست!

    یک روز موتور یک کشتی بزرگی خراب شد.
    مهندسان زیادی تلاش کردند تا مشکل را حل کنند اما هیچکدام موفق نشدند!
    سرانجام صاحبان کشتی تصمیم گرفتند مردی را که سال‌ها تعمیر کار کشتی بود، بیاورند...

    وی با جعبه ابزار بزرگی آمد و بلافاصله مشغول بررسی دقیق موتور کشتی شد.
    دو نفر از صاحبان کشتی نیز مشغول تماشای کار او بودند.
    مرد از جعبه ابزارش آچار کوچکی بیرون آورد و با آن به آرامی ضربه ای به قسمتی از موتور زد، بلافاصله موتور شروع به کار کرد و درست شد.

    یک هفته بعد صورتحسابی ده هزار دلاری از آن مرد دریافت کردند، صاحب کشتی با عصبانیت فریاد زد:

    او واقعا هیچ کاری نکرد!
    ده هزار دلار برای چه می خواهد بگیرد؟

    بنابراین از آن مرد خواستند ریز صورتحساب را برایشان ارسال کند؟
    مرد تعمیر کار نیز صورتحساب را اینطور برایشان فرستاد:

    ضربه زدن با آچار: ۲دلار
    تشخیص اینکه ضربه به کجا باید زده شود: ۹۹۹۸ دلار

    و ذیل آن نیز نوشت:

    تلاش کردن مهم است.
    اما دانستن اینکه کجای زندگی باید تلاش کرد می‌تواند همه چیز را تغییر بدهد.

     

     

  6. Max Base
    آخرین نوشته

    توسط Max Base،

    سلام.

    عدم دسترسی به یک سیستم مناسب و با خبر نبودن از حساب کاربری گیت هاب خود یکی از مشکلاتی بود که در این چند ساله برنامه نویسان با آن روبرو بودند.

    چک کردن حساب ایمیل در تلفن همراه می توانست تا حدودی به این موضوع کمک کند. اما یک اپلیکیشن اختصاصی برای این مورد می تواند این امر را به بهترین شکل پوشش دهد.

    بعد از کارهایی که برروی اپلیکیشن رسمی شرکت گیت هاب برای پلتفرم iOS انجام شد و خوشبختانه بدون هیچ مشکلی در بزرگ رویداد و کنفرانس شرکت و مایکروسافت - GitHub Universe 2019 در تاریخ November 13-14, 2019 رونمایی شد. به عنوان یکی از اعضای شرکت این نوید را می دهم که نوبت به آن رسید تا اپلیکیشن برای اندروید نیز پیاده شود.

    در حال حاضر این اپلیکیشن در حال توسعه است و هنوز رونمایی نشده است.

    برای این اپلیکیشن میزان پشتیبانی API 21+ Android device در نظر گرفته شده است و خواهد توانست از نسخه Android 5.0 به بالا را پشتیبانی کند.

    می توانید پیشنهادات و نظرات خود را نیز ایمیل کنید. Max [@] Asrez {.DOR.} com

    Hi, I'm Max Base.

    GitHub team did work on the official GitHub application for the iOS platform and fortunately unveiled at the big event and conference(GitHub Universe 2019 on November 13-14, 2019). As a member of the company, I have the promise that the app will launch for Android.

    This app is currently under development and has not been unveiled yet.

    This app is designed to support Android 21+ API and will support Android 5.0 or later.

    You can also email your suggestions and comments. Max [@] Asrez {.DOR.} com

    Best,

    Max Base

    GitHub-APP-iOS.jpg

     

    1546157682482731460_mobile-work-all-2.pn

    29235157682482727545_mobile-triage-all.p

     

    3900157682482736585_mobile-nigode-all--m

    4116015768248237796_mobile-nigode-all.pn

    7086157682482713148_mobile-contribute-al

    11133157682483611776_mobile-beta-all.png

    با تشکر

    Max Base / مکس بیس

  7. دو هفته پیش، نشست ۲۰۱۸ سی‌پلاس‌پلاس آغاز شد. شرکت کننده‌ها مدال‌های خودشان را دریافت کردند چرا که همه‌ چیز با هماهنگی بسیار خوبی به پایان رسید. این رویداد به عنوان یکی از چندین رویداد مهمC++ بشمار می‌رود که هرساله توسط حامیان و علاقه‌مندانش برگزار می‌شود.

     

    سخنان کلیدی

    امسال در این رویداد سه یادداشت کلیدی وجود داشت، که با حضور Andrei Alexandrescu ،Lisa Lippincott و Nicolai Josuttis ارائه شد.

    IMG_0399_600.JPG

    اولین سخنران Andrei Alexandrescu بود، او این کنفرانس را با افکار و اندیشه‌های خودش برای شروع آغاز کرد عنوان موضوع آن به بَد بودنِ کپی constexpr از static if اشاره می‌کرد. او یک سخنران سرگرم کننده است، بنابراین سخنرانی او بسیار طبیعی در مورد یادداشت‌های خودش منعکس می‌شد. همچنین او به عنوان یک توسعه‌دهندهٔ ++C به نقاط بسیاری اشاره کرد که کمیتهٔ استاندارد سازی زبان حرف‌های او را تایید می‌کرد.

    IMG_0620_600.JPG

    سخنران دوم Lisa Lippincott روز دوم را با یک سخنرانی آغاز کرد که دیدگاه‌های مختلفی در مورد محاسبات و منطق که در آن به کار می‌رود ارائه داد. زمانی که مُجری لیزا را دعوت کرد، می‌دانست که این موضوع به عنوان یک نکته مهم برای فکر کردن است، چیزی که همه نمی‌توانند به طور مستقیم آن را درک کنند و به آن دسترسی پیدا کنند. اما این تلنگری برای نحوهٔ درک کُد از دیدگاه ریاضی و دیدگاه جدیدی بود.

    IMG_1000_600.JPG

    سخنران سوم و آخر Nicolai Josuttis بود که در مورد، او اولین سخنران در نشست Hartmut Kaiser در سال ۲۰۱۴ بود. در آن سخنرانی بسیار خوب درخشیده، بنابراین در قسمت سوم نقص‌هایی را با جزئیات در مورد نقاط خشن ++C نشان داد. این سخنرانی بسیار صادقانه بود! چرا که بسیاری از جزئیات خشن بودن سی‌پلاس‌پلاس را عنوان کرد که همگی با آن موافق بودند.

     

    مذاکرات، مسابقه و گفتگوها‌ی چند دقیقه‌ای

    جلسات و رویداد‌های مرتبط با ++C همیشه گفتگو‌های بسیار خوبی دارد، و با یک مسیر مشخص که هدفش آوردن سخنرانان جدید با دیدگاه‌های جدید است برگزار می‌شود. بازخورد سخنران‌ها در این رویداد خوب بود چرا که به برخی از نکات در مورد چگونگی بهبود‌ها اشاره کردند.

    IMG_0728._600.JPG

    IMG_0871_600.JPG

    تصویر بالا مربوط به Hana Dusíková است که می‌توان به آن بهترین نمره را داد. بهترین سخنرانی هم مربوط به  Andrei Alexandrescu بود که دنبال شد. در اولین عصر این رویداد، امتحان (Quiz) برجسته‌ترین مورد رویداد در آن روز بود. سازماندهی آن توسط Diego  و اسپانسری آن توسط Conan است که برای چند سال اخیر حمایت شده است. به نظر می‌رسید که سوالات امتحانی این سال سخت‌تر از سوالات رویداد قبلی در سال گذشته بوده است. اما بار دیگر این سرگرمی ترکیب بسیار خوبی با ترس از سی‌++ را داشت.

    هر یک از سوالات امتحانی یک خروجی از کُد را تولید می‌کردند، که هر گروه باید برای کسب امتیاز آن را می‌نوشتند. ده نوع کُد امتحانی وجود داشت که تهیه کنندهٔ گزارش برای به تصویر کشیدن آن‌ها زیاد خوب عمل نکرده است. بنابراین تصویر زیر مربوط به سوالات چالشی در مورد سی‌پلاس‌پلاس است:

    IMG_0542_600.jpg

    گفتگو‌های کوتاه در طی جلسات سی‌پلاس‌پلاس صورت می‌گیرد. اما در سال‌های گذشته روش به گونه‌ای تغییر یافته است که سوالات پرسیده شده باید با گفتگو‌ها و سوالات دیگر رقایبت می‌کردند. با این حال این یک قالب و روش جالبی بود که نتیجهٔ موفقیت آمیزی را داشت. همهٔ شرکت کننده‌ها می‌توانستند این سوالات رو ببینند و در مورد آن‌ها تفکر کرده و پاسخ دهند.

    • نقل قول

      نتیجه : این رویداد بیشتر به عنوان یک دوره‌همی و گفتگو در مورد رفتار‌های خشن زبان سی‌پلاس‌پلاس و پاسخ‌های سرگرم کننده در مورد آن‌ها را فراهم کرده است و به ویژگی‌های جدید زبان در آن پرداخته نشده است.

    نکته: شما می‌توانید تصاویر ویدیویی مربوط به این رویداد را از کانال رسمی آن در یوتیوب دریافت کنید.

     

×
×
  • جدید...