رفتن به مطلب
جامعه‌ی برنامه‌نویسان مُدرن ایران

برنامه نویسی

  • مطالب
    5
  • دیدگاه‌ها
    2
  • باز‌دید‌ها
    502

شرکت کنندگان در این وبلاگ

درباره‌ی این بلاگ

Entries in this blog

 

اسکریپتینگ در ++C

کامپایلر Cling یک مترجم تعاملی برای سی‌پلاس‌پلاس است، این مترجم تحت بالاترین کتابخانه‌های Clang و LLVM ساخته شده است. در واقع از آن‌جایی که کامپایلر Clang از آخرین ویژگی‌ها و استاندارد‌های زبان سی‌پلاس‌پلاس پشتیبانی می‌کند، Cling اجازه می‌دهد تا توسعه‌دهندگان اسکریپت‌های خود را با استفاده از C و C++ بنویسند. اگر شما به طور مستقیم مترجم را اجرا کنید، یک محیط زنده برای آغاز برنامه نویسی با سی‌پلاس‌پلاس را خواهید داشت که به عنوان بخشی از استاندارد نحو سی و سی‌پلاس‌پلاس به شمار می‌آید. همچنین می‌توانید دیگر دستورات را با نقطه‌ی "." آغاز در اختیار داشته باشید. وقتی از مترجم تعاملی استفاده می‌کنید، می‌توانید کد زیر را بنویسید: #include <stdio.h> printf("hello world\n"); همانطور که می‌بینید نیازی نیست تا در مورد حوزه‌ی دامنه‌ها نگران باشید؛ کافی است شما تابع مورد نظر خود را صدا بزنید. اگر قصد شما این است که از Cling به عنوان یک مترجم برای ساخت اسکریپت‌ها استفاده کنید، باید همه چیز را در داخل یک تابع قرار دهید.چرا که نقطه‌ی ورود به اسکریپت به طور پیش‌فرض همانند نام فایل می‌باشد. می‌توان آن را برای صدا زدن دیگر توابع سفارشی سازی کرد. بنابراین مثال قبل می‌توانید به شکل زیر تغییر کند: #include <stdio.h> void _01_hello_world() { printf("foo\n"); } یک نسخه‌ی دیگر در قالب سی‌پلاس‌پلاس #include <iostream> void _02_hello_world() { std::cout << "Hello world" << std::endl; } مثال‌ها کاملاً ساده هستند، اما آن‌ها به شما نشان می‌دهند که چگونه باید شروع کنید. در مورد کیوت چطور؟ #include <QtWidgets/qapplication.h> #include <QtWidgets/qpushbutton.h> void _03_basic_qt() { int argc = 0; QApplication app(argc, nullptr); QPushButton button("Hello world"); QObject::connect(&button, &QPushButton::pressed, &app, &QApplication::quit); button.show(); app.exec(); } اما توجه داشته باشید که کد قبلی کار نخواهد کرد، شما باید برخی از پارامتر‌های سفارشی را در Cling مشخص کنید. cling -I/usr/include/x86_64-linux-gnu/qt5 -fPIC -lQt5Widgets 03_basic_qt.cpp شما می‌توانید Cling را برای خودتان بر اساس آن چیزی که برای اسکریپت خود نیاز دارید سفارشی سازی کنید. همچنین شما می‌توانید Cling را به عنوان یک کتابخانه در اپلیکیشن‌های خود آورده و از سی‌پلاس‌پلاس به عنوان زبان برنامه‌نویسی استفاده کنید. این پُست در آینده ادامه خواهد داشت. 🙂
 

شرکت Ceemple کامپایلر Zapcc خود را تحت مجوز منبع باز منتشر کرد

درباره‌ی کامپایلر Zapcc کامپایلر Zapcc یک کامپایلر بر پایه Clang است که با هدف کامپایل‌های سریعتر طراحی شده است. این کامپایلر با استفاده از حافظه نهان (Cache) و استفاده از معماری سرویس‌گیرنده-سرویس‌دهنده پیاده سازی شده است که یک کامپایلر مدرن و جدیدی به شما می‌آید که برای اهداف زیر ساخته شده است: ساخت سریع: تسریع در جمع آوری‌های قابل توجه برای هدرهایی که دارای قالب‌های سنگین در سی پلاس پلاس می‌باشند مانند LLVM، WebKit، ScyllaDB بر پایه Clang/LLVM: این کامپایلر بر پایخ Clang و اغلب بر ساس آخرین SVN به روز رسانی شده است. پشتیبانی کامل از لینوکس: در حال حاضر این کامپایلر از لینوکس x64 و ویندوز x64 با MinGW-w64 به صورت آزمایشی پشتیبانی می‌کند. جایگزینی: جایگزینی برای Clang و GCC و پشتیبانی از تمامی سیستم‌های ساخت (Build Systems) . مجوز‌ها این پروژه منبع باز تحت مجوز LLVM از (University of Illinois/NCSA) می‌باشد. ساخت (Building) پیش نیازها و فرآیند ساخت همانند LLVM می‌باشد. git clone https://github.com/yrnkrn/zapcc.git llvm mkdir build cd build cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_WARNINGS=OFF ../llvm ninja اجرا و آزمایش ninja check-all استفاده نحو دستورات Zapcc همانند دستورات Clang می‌باشد. از بین بردن سرور Zapcc pkill zapcc این دستور جهت از بین بردن سرور Zapcc برای آزاد سازی حافظه یا جایگزینی با سیستم تازه ساخته شده Zappc استفاده شود. جهت اطلاعات بیشتر به این بخش مراجعه کنید. لینک منبع بر روی گیت‌هاب
 

شش دلیلی که باید نسخه نگاری را کنترل کنید

برای بسیاری از توسعه دهندگان نرم افزار کار کردن بدون کنترل نسخه غیر قابل تصور است. فواید کنترل و پیگیری تاریخچه تغییرات کدها برای درک کردن دنیای توسعه نرم افزار بسیار بالاست. با توجه به این نباید از نتایج به دست آمده از تحقیق انجام شده توسط DevOps که استفاده از تاریخه کدها بسیار بالاست شگفت زده شد. اما پرسیدن در مورد کنترل نسخه دیتابیس موضوع دیگری است. تنها ۵۸ ٪ از کسانی که در این تحقیق شرکت کرده اند گفته اند که کنترل نسخه دیتابیسشان را رصد می‌کنند. البته به طریقی این قابل درک است که چرا کنترل نسخه برای مدت بسیار زیادی بر روی دیتابیس انجام نمی پذیرفت. اما اکنون زمان این رسیده است که دیگر تیم‌ها بتوانند بر روی دیتابیس کار کنند. اگر شما هنوز کنترل نسخه برای دیتابیس خود انجام نداده اید ما در اینجا دلایلی آورده ایم که اینکار برای شما بسیار حیاطی می‌باشد: به راحتی می‌توانید تغییرات کدها را با تیمتان به اشتراک بگذارید
کنارهم قرار دادن دیتابیس کد‌ها با سیستم کنترل نسخه کار کردن اعضای تیم بر روی کدهای دیتابیس و مسئولیت پذیری آن‌ها را بر روی کارهایشان بیشتر می‌کند. توانایی به اشتراک گذاردن مداوم و مدیریت تغییرات برای تیم های که در کنار هم کار نمی کنند بسیار حیاتی است. به وسیله  SQL Sourse Control   اعضای می توانند بر روی یک دیتابیس به اشتراک گذارده شده و یا هر کدام بر روی یک دیتابیس LOCAL که یک کپی از نسخه اصلی است کار کنند. با افزودن ویژگی‌هایی مانند object locking شما می می‌توانید از تداخل های احتمالی جلوگیری کنید و کار را بدون تداخل جلو ببرید. از نحوه توسعه نمای بهتری به دست خواهید آورد:
سیستم کنترل نسخه برای شما یک نمای کلی از توسعه کلی کاری که انجام می‌دهید نشان می‌دهد. کنترل نسخه برای شما تاریخچه تغییرات را نشان می‌دهد و به راحتی با سیستم های کنترلی و پیگیری کار ‌می‌کند. به طور مثال SQL Source Control به شما اجازه همگام سازی وظایف دیتابیس را با Mircosoft Team Foundation Server work item ها می‌دهد و به وسیله آن به راحتی می توانید جریان کار را کنترل کنید. به شما توانایی Rollback و بازگشتن به ورژن قبلی دیتابیس را می‌دهد.
در حالی که شما همواره یک استراتژی Backup مناسب دارید. استفاده از کنترل نسخه برای دیتابیس یک مکانیزم برای back up  گرفتن از SQL کدهای شما در اختیارتان قرار می‌دهد. با استفاده از SQL Source Control کار کردن و بازگرداندن نسخه های قبلی بسیار آسان و ساده هستند. حسابرسی و خوانایی کدها را ساده‌تر می کند
تغییر ورژن کنترل،‌اولین قدم برای آماده سازی خوانایی کدها و یک قدم ضروری برای بهتر کردن حسابرسی و مدیریت ریسک می‌باشد. حسابرسی صحیح نیازمند یک سازماندهی برای کلیه تغییران بر روی دیتابیس می‌باشد و آن نیازمند جزییان برای دسترسی است. با استفاده از SQL Source Control شما می‌توانید نسخه کامل تاریخچه دیتابیس و یا database object را دسترسی داشته باشید و ببینید که چه کسی تغییرات را ایجاد کرده است، چه زمانی آنها را انجام داده است و چرا. پایه ریزی برای Database Automation
داشتن یک نسخه از دیتابیس مدیریت تغییرات را ساده تر می‌کند. پردازش‌های پیچیده اتوماتیک‌تر و تکرارپذیرتر می‌شوند و تغییرات نیز قابل پیش‌بینی می‌گردند. استفاده از کدی که در داخل SQL Source Control به عنوان پایه ساختن و تست های DLM Automation را اتوماتیک می‌کند و این بدین معنی است که مسائل سریع‌تر پیدا می‌شوند و کدی با کیفیت بالاتر تولید و منتشر می‌گردد. همگام‌سازی دیتابیس و تغییرات کد‌های نرم‌افزار
داشتن یک دیتابیس با کنترل نسخه دقیقا در کنار اپلیکیشن تغییرات کد‌های دیتاییس و اپلیکیشن را همگام می‌کند. شما همواره خواهید دانست که چه نسخه‌ای از کد بر روی چه ورژنی از نرم‌افزار قرار داده شده است. این به شما کمک می‌کند تا انجام پروژه به صورت تیمی را بسیار ساده‌تر کنید، اثربخشی کار را بالاتر ببرید و مشکلات را سریع تر برطرف کنید. SQL Source Control که به سیستم های کنترل نسخه مانند TFS, Git, Subversion متصل شود تغییرات کدها را ذخیره می‌کند. خلاصه:
در حالی که این مساله صحیح است که کنترل نسخه همواره به دست نمی‌اید، اما در دسترس بودن ابزارهایی مانند SQL Source Control به این معنی است که دیگر دلیلی برای بعضی از شرکت‌ها که این کار انجام می‌دهند نباشد. اگر شما یکی از ۴۲ ٪ هستید که تا اکنون این کار برای دیتابیس خودتان انجام نداده اید، شاید این ۶ دلیل بالا بتواند نظر شما را عوض کند.
 

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

فرق بین کامپایل استاتیک و داینامیک قبل از اینکه فرق بین ایستا (استاتیک) - Static و پویا (داینامیک) - Dynamic را بدانیم لازم است در رابطه با چرخه زندگی نوشتن یک برنامه و اجرای آن آشنا شویم. هر برنامه برای اولین بار توسط یک محیط توسعه (Editor) یا IDE توسط برنامه نویسان انتخاب و به صورت فایل متنی قابل ویرایش می باشد. سپس فایل متنی که شامل کد های نوشته شده توسط برنامه نویس تحت زبان برنامه نویسی مانند C، C++ و غیره... می باشد توسط کامپایلر به کد شیء ای تبدیل می شود که ماشین بتواند آن را درک کرده و اجرا کند. برنامه ای که ما می نویسیم ممکن است به عنوان یک مورد توسط دیگر برنامه ها یا کتابخانه هایی از برنامه ها مورد استفاده قرار بگیرد برقراری ارتباط (پیوند کردن) یا همان لینک کردن پروسه ای است که برا اجرای موفقیت آمیز برنامه های نوشته شده ما بکار می رود برقراری ارتباط بین ایستا و پویا دو پروسه ای از جمع آوری و ترکیب فایل های شیئ های مختلفی است که به منظور ایجاد یک فایل اجرایی می باشند. در این بخش ما تصمیم بر این داریم تا تفاوت بین آن ها را با جزئیات مورد بررسی قرار دهیم. عمل پیوند یا ترکیب در زمان کامپایل انجام شود، در واقع زمانی که کد منبع به زبان ماشین ترجمه می شود، در زمان بار گذاری، زمانی که برنامه در داخله حافظه بار گذاری می شود، و حتی زمان اجرای آن توسط برنامه صورت می گیرد این عمل زمان پیوند و یا ترکیب (اتصال) است. در نهایت این فرآیند توسط برنامه ای اجرا می شود که به آن لینکر - پیوند دهنده (ترکیب کننده) می گویند. اتصال دهنده ها به عنوان ویرایستار لینک نیز معرفی می شوند. لینک شدن (پیوند شدن) به آخرین مرحله از کامپایل می گویند. در زبان علمی اصطلاح لینکر یا Linker معروف است اما در زبان فارسی بهترین گزینه مربوطه را میتوان با عنوان اتصال دهنده، پیوند دهنده، ترکیب کننده نام برد. همه آن ها نشانگر یک هدف به منظور ترکیب اشیاء با یکدیگر هستند که در مرحله کامپایل صورت می گیرد. پس از ایجاد پیوند در برنامه، برای اجرای آن برنامه باید داخل حافظه منتقل شود. در انجام این کار باید آدرس هایی برای اجرای داده ها و دستور العمل ها اختصاص یابد. به طور خلاصه روند زیر می تواند به عنوان چرخه زندگی یک برنامه خلاصه شود (نوشتن - لینک کردن - بارگذاری - اجرا) فرق بین کامپایل استاتیک و داینامیک در زیر تفاوت های عمده ارتباط بین استاتیک و داینامیک آورده شده است : استاتیک  ارتباط به روش استاتیک فرآیندی است که تمامی ماژول ها و کتابخانه های برنامه در فایل اجرایی نهایی کپی می شوند. این روش توسط لینکر در مرحله آخر کامپایل انجام می شود. اتصال دهنده - لینکر طبق روال ترکیبی کتابخانه ها را با کد برنامه و همراه مراجع - منابع خارجی ترکیب کرده و برای تولید یک بارگذاری مناسب در حافظه آماده سازی می کند. زمانی که برنامه بار گذاری می شود، سیستم عامل محلی را در حافظه به صورت یک فایل اجرایی که شامل کد های اجرایی و داده ها می باشد مشخص می کند. ارتباط به شیوه استاتیک توسط برنامه ای با نام لینکر انجام می شود که در آخرین مرحله فرآیند کامپایل یک برنامه صورت می گیرد. لینکر ها نیز به عنوان ویرایشگر پیوند نیز عنوان می شوند. فایل های استاتیک به طور قابل توجهی دارای اندازه بسیار بزرگی هستند زیرا برنامه های خارجی و کتابخانه های لینک شده همه در یک جا و در فایل نهایی اجرایی جمع آوری شده اند. در اتصال استاتیک اگر هر یک از برنامه های خارجی تغییر کرده باشد باید آن ها دوباره کامپایل شوند و مجددا عمل اتصال صورت گیرد در غیر اینصورت هیچ تغییری در به روز رسانی های مرتبط با فایل اجرایی مشاهده نخواهد شد. برنامه های استاتیکی زمان بارگذاری ثابتی در هر بار اجرای برنامه در حافظه را در نظر می گیرند. و زمانی که برای بارگذاری طول می کشد ثابت است. برنامه هایی که از کتابخانه های استاتیکی استفاده می کنند معمولا سریعتر از برنامه هایی هستند که کتابخانه های آن ها به صورت پویا می باشد. در برنامه های استاتیکی، تمامی کد ها شامل یک فایل اجرایی می باشند. بنابراین، آن ها هرگز در برنامه هایی که دارای مشکلاتی هستند اجرا نخواهند شد. داینامیک در ارتباط پویا نام کتابخانه های خارجی (کتابخانه های به اشتراک گذاری شده) در فایل اجرایی نهایی قرار داده شده اند نه خود کتابخانه. در حالی که ارتباط واقعی در زمان اجرا در هر دو فایل در حافظه قرار می گیرند. اتصال پویا این اجازه را می دهند تا برنامه های متعددی به صورت یک ماژول کپی شده و قابل اجرا مورد استفاده قرار بگیرد. اتصال پویا بر خلاف اتصال استاتیک در زمان اجرا توسط سیستم عامل انجام می شود. در اتصال پویا فقط یک نسخه از کتابخانه به اشتراک گذاری شده در حافظه نگه داری می شود. این به طور قابل توجهی اندازه برنامه های اجرایی را کاهش می دهد، در نتیجه صرفحه جویی در حافظه و فضای دیسک صورت خواهد گرفت. در اتصال پویا بر خلاف اتصال استاتیک نیازی به کامپایل کامل پروژه نمی باشد در صورتی که لازم باشد تغییراتی در هر یک از فایل ها صورت بگیرد تنها کافی است آن را کامپایل و در کنار برنامه قرار دهید. این یکی از بزرگترین مزیت های کامپایل داینامیکی می باشد. در اتصال پویا زمان بارگذاری برنامه در حافظه ممکن است کاهش یابد. این در صورتی است که کتابخانه های مشترک در حافظه بارگذاری شده اند. برنامه هایی که از کتابخانه های مشترک استفاده می کنند معمولا کندتر از برنامه هایی هستند که از کتابخانه های استاتیکی استفاده می کنند. برنامه های پویا وابسته به داشتن کتابخانه های سازگار هستند. اگر کتابخانه تغییر یابد (برای مثال، یک کامپایلر جدید منتشر شود ممکن است کتابخانه را تغییر دهد)، در این صورت ممکن است برنامه مجدداً تحت کتابخانه جدید باز نویسی و به روز رسانی شوند. اگر کتابخانه از روی سیستم حذف شود، برنامه ای که وابسته آن کتابخانه می باشد دیگر کار نخواهد کرد.
 

چه کسانی Full-Stack Developer هستند

برنامه‌نویس تنها در این عنوان خلاصه نمی‌شود و لازم است بدانید که برنامه‌نویسان در چند دسته متفاوت وجود دارند که برخی از آن ها به صورت Back-End و برخی Front-End فعالیت می‌کنند. در کل به کسانی که توانایی برنامه نویس در بخش Back-End را دارند به آن‌ها Back-End Developer می‌گویند. همچنین برنامه‌نویسانی که توانایی توسعه در بخش طراحی رابط کاربری و تجربه کاربری را با عنوان Front-End دارند Front-End Developer می‌گویند. در زیر یک اینفوگرافیک برای مشخص سازی وظایف برنامه‌نویسان درج شده است که در این مرحله تنها به وظایف آن‌ها اشاره دارد نه به چرخه تولید نرم افزار، بنابراین در اینفوگرافیک‌های بعدی به چرخه همزمان تولید و توسعه خواهیم پرداخت. یک برنامه‌نویس حرفه ای یا همان فول اِستک دولپر می‌بایست مهارت‌های زیر را دارا باشد: مسلط به زبان‌های برنامه‌نویسی پایه آشنایی با UX و UI کنترل کیفیت محصول انواع فناوری‌ها و کتابخانه‌ها انواع دیتابیس و مدیریت آن‌ها هک و امنیت بهینه سازی موتور‌های جستجو درک نیاز‌های کاربران در محصول آشنایی با سیستم عامل‌های مختلف آشنایی با کراس پلتفرم آشنایی با شبکه آشنایی با مدیریت سرور و هاستینگ آشنایی با سیستم های مدیریتی و مجازی مانند VM آشنایی با سخت افزار آشنایی با رابط های برنامه نویسی API ها آشنایی با انواع محیط های توسعه و موارد دیگر که در یک پروژه از صفر تا صد می‌توان به آن‌ها نیاز پیدا کرد  برنامه‌نویسان Full-Stack Developer به تنهایی می‌توانند درتولید و توسعه یک محصول موثر باشند و زمانی که با مشکلی مواجه شوند نمی‌گویند من آن را بلد نیستم، بلکه حتما آن را حل خواهند کرد. به طور کلی کسب مهارت در سطح بالا در حد یک توسعه‌‌ دهنده فول است بسیار سخت است اما نباید بگوییم که غیر ممکن است، در صورتی که چنین تعریفی برای یک توسعه‌دهنده‌ی فول‌استک در نظر بگیریم، بدون اغراق باید گفت تعداد اندکی از این برنامه‌نویسان موجود است که بتوانیم چنین لقبی را به آن‌ها اختصاص بدهیم بنابراین چنین برنامه‌نویسانی بسیار ارزشمند هستند  لذا به خوبی می‌دانند یک نرم افزار چگونه طراحی‌ می‌شود و توانایی این را دارند از صفر تا صد یک نرم‌افزار را طراحی و روانه بازار کنند. علاوه بر این توسعه دهنده Full-Stack کسی است که واژگانی مانند نبود، نمیشه، امکان نداره، نمیتوم، کار من نیست و ... را بر زبان نمی‌آورند و اگر هم چیزی را ندانند تمام تلاش خود را می‌کنند تا بدون نیاز به کمک شخصی دیگر آن را حل کنند. این نوع توسعه‌‌دهنده‌ها بسیار با ارزش و مهم هستند، و نکته جالب اینجاست که آن‌ها سال‌ها تلاش کرده اند و مسلماً به تنهایی صاحب کسب‌و‌کار خود بوده و برای کسی کار نمی‌کنند. برای توسعه دهنده‌ی فول‌اِستک فرقی نمی‌کند محصول تحت چه پلتفرمی باشد، او می‌تواند تحت دسکتاپ، وب، موبایل و دیگر پلتفرم ها آن را تولید کند.
×