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

اگر شما توسعه‌دهنده هستید، مسلماً بار‌ها به دنبال بررسی کاربرد یک دستور، تابع یا کلاس خاصی در یک زبان برنامه نویسی بوده‌اید. بنابراین مراجعه به مراجع زبان‌ و یا زبان‌های برنامه‌نویسی ای که شما با آن کار می‌کنید یکی از راه‌کار‌هایی است که می‌توانید به پاسخ صحیح در رابطه با نیاز خود برسید. من قصد دارم ابزار یا به اصطلاح سرویس دهنده‌ای را برای شما معرفی کنم که به شما امکان دسترسی بسیار ساده و کار‌آمد به مستندات تمامی زبان‌های رایج را فراهم می‌کند. معرفی سرویس DevDocs مستندات رابط‌های برنامه‌نویسی متعددی را باهم ترکیب و در قالب یک رابط کاربری سریع، سازمان یافته شده و قابل جستجو و در دسترس را فراهم کرده است. در اینجا آن چیزی را که قبل از شروع استفاده باید بدانید آورده ایم. خلاصه‌ای از ویژگی‌ها جهت دسترسی به تنظیمات رابط کاربری و سفارشی سازی محیط به بخش Prefrences مراجعه کنید. در صورتی که مایل به استفاده از ماوس نیستید می‌توانید از میانبر‌های کلیدی بسیار ساده و کارآمد استفاده کنید که در این بخش معرفی شده اند. جستجوی خاص و ساده پشتیبانی از قالب (fuzzy) به شما اجازه خواهد داد تا با خلاصه نویسی مانند (bgcp) به نتیجه (background-clip) برسید. برای جستجوی اسناد خاص با تایپ کردن خلاصه آن و سپس فشردن کلید tab می‌توانید به آن‌ها دسترسی داشته باشید. همچنین شما می‌توانید با استفاده از نوار آدرس مرورگر بخ نتایج جستجوی خود دسترسی داشته باشید. سرویس DevDocs در حالت آفلاین٫ در نسخه موبایل و افزونه‌ای که می‌تواند بر روی مرورگر گوگل کروم نصب شود در دسترس خواهد بود. جهت دنبال کردن آخرین رخداد‌ها و اخبار‌ها در باره این سرویس آن را در توئیتر می‌توانید با آدرس DevDocs@ دنبال کنید. سرویس DevDocs به طور کامل منبع باز است و سورس آن بر روی گیت‌هاب در دسترس است. در صورتی که شما یک کُدر و یا برنامه‌نویس مبتدی هستید می‌توانید از این مرجع نیز استفاده کنید. نسخه آفلاین جهت نصب نسخه‌های آفلاین به این بخش مراجعه و گزینه مورد نظر خود را انتخاب کنید. پلاگین و افزونه‌ها وب اپلیکیشن مخصوص گوگل کروم اپلیکیشن دسکتاپ پکیج Sublime پکیج Atom افزونه Visual Studio Code افزونه‌ها و ابزار‌های بیشتر...

تحول توسط اینترنت اشیاء (IoT)، این واضح است که افزوده شدن به تعداد دستگاه های متصل به این فناوری با سرعت چشمگیری در حال افزایش است. همه جا در اطراف زندگی روزمره ما، استفاده بیشترو بیشتری را از آن ها داریم. علاوه بر این که به آن ها متصل هستیم، دستگاه های با صفحه لمسی بیشتری به رابط گرافیکی مدرن مجهز می شوند. در این میان در اطراف ما به راحتی دیده می شود که کاربران زیادی نرم افزار های خود را توسط کیوت برای این دستگاه ها می سازند. برای رسیدن به شماری از این اعداد و ارقام توسط گروه Gartner که تخمین زده است تا سال ۲۰۲۰ رشد دستگاه های متصل به این فناوری حدود ۲۰٬۷ میلیارد دستگاه خواهد بود. (حتی پیش بینی شده است که بالاتر از آن یعنی حدود ۳۰ میلیارد دستگاه) مجهز به فناوری مرتبط خواهد شد که تحت سی پلاس پلاس و کیوت توسعه پیدا می کنند. نه تنها شمار زیادی از دستگاه ها در حال رشد هستند، اما در این میان پیچیدگی و تعداد نرم افزار ها نیز در حال رشد هستند. برای مثال، امروزه خودرو ها می‌توانند بیش از ۱۰۰ میلیون خط کد را در اختیار داشته باشند، انتظار می رود این روند به سه برابر در آینده به عنوان قابلیت های نرم افزاری در خودرو ها افزایش یابد. خودرو ها بخش پیچیده ای از این فرآیند محسوب می شوند، اما حتی برای ساده ترین اتصال به دستگاه ها نیاز به نرم افزار های زیادی می باشد که قادر باشند الزامات را برای اتصال به طور امن با قابلیت های مفید را با رشد چشم گیری در اختیار مصرف کنندگان قرار دهند. در اینجا بر روی یک نمودار خطی چگونگی دستگاه های در حال رشد را تخمین می‌زنیم: در داخل این دستگاه ها چه چیزی وجود دارد؟ چه نوع نرم افزاری دستگاه های متصل شده را مدیریت می کند؟ چه نوع مهارت هایی برای ساخت اینها نیاز است؟ اینگونه تخمین زده شده است که تا به امروز 95% از دستگاه های تعبیه شده (Embedded) اِمبد ها توسط زبان برنامه نویسی C و ++C ساخته شده اند، و اینگونه پیشبینی شده است که این فرآیند در آینده به طور قابل توجهی تغییر نخواهد یافت. سپس، از سوی دیگر با توجه به مطالعاتی که در جهان بر روی ۴.۴ میلیون توسع دهنده C++ و ۱.۹ میلیون توسعه دهنده زبان C در سال ۲۰۱۵ صورت گرفته است. یک مطالعه بر اساس نتایج سال ۲۰۰۱ توسط IDC، نشان می دهد که تعداد توسعه دهندگان زبان ++C در آن زمان حدود ۳ میلیون نفر بوده است. معنی این نتایج اینگونه است که تعداد توسعه دهندگان ++C به طور پیوسته در حال رشد است که حدود 3% در سال بوده و انتظار می روند با همین روند به جمع توسعه دهندگان در سال های آتی افزوده شود. بنابراین، یک تجسم کلی از رشد توسعه دهندگان ++C در نمودار زیر آورده شده است: بر اساس برآورده های تعداد دستگاه های تخمین زده شده، که اکثر آن ها باید توسط C و ++C انجام شده باشند، و در حال حاضر با سرعت بسیار زیادی همین روند رو به رشد می باشد و انتظار می رود این روند با سرعت بسیار بیشتری ادامه یابد. با توجه به افزایش پیچیدگی در عملکرد، تعداد نرم افزار های موجود در حال رشد است. اگرچه برخی از دستگاه های جدید از عملکرد بسیار ساده ای برخوردار خواهند بود، اما دستگاه های بسیار بیشتری با پیچیدگی های بیشتری مورد نیاز مصرف کنندگان است. در حال حاضر، این مقایسه بین دو گرایش معمای جالبی را برای ما فراهم می کند که توجه به آن جالب است: چطور میلیون ها نفر از توسعه دهندگان سی‌پلاس‌پلاس نیازمندی ها را برای ساخت و متصل کردن میلیاردها دستگاه به یکدیگر مطابقت می دهند. با قرار دادن این دو نمودار در کنار هم، می توانیم به وضوح نمودار پارادوکس را تجسم کرده و به یک (راه حل) ممکن برسیم: بنابراین چگونه بر آن افزوده می شود؟ آیا ما انتظار این را خواهیم داشت که در سال ۲۰۲۰ یک توسعه دهنده سی‌پلاس‌پلاس ۲۰ برابر بیشتر از آن چیزی را بنویسد که در ۱ دهه قبل نوشته است؟ این راه حل کارساز نخواهد بود. حتی اگر همه توسعه دهندگان ++C تمرکزشان بر روی دستگاه ها باشد! لذا هنوز توسعه دهنده ++C به اندازه کافی موجود نیست. توسعه دهندگان C++ به راحتی می توانند آموزش های حرفه ای را ببینند و سال هایی را برای دوره های خود در نظر بگیرند تا به درجه استادی برسند. بنابراین، چیزی که باید انجام شود دو چیز است: فعال کردن توسعه دهندگان C++ در این زمینه ها و همچنین آموزش برای برنامه نویسان غیر ++C برای ساخت دستگاه ها. بنابراین، برای تعبیه شدن نیاز ها باید با شرایط جدیدتری سازگار شد. تنها راه برای مقابله با رشد این است که ابزار های خوبی برای دستگاه ها در اختیار قرار گیرد. پیش بینی می شود با ابزار هایی که Qt قرار است فراهم کند رویکرد قابل قبولی برای ساخت دستگاه ها فراهم آورد. زیرا شعار کیوت این است "کد کمتر،سازندگی بیشتر، تولید و استقرار در همه جا" این شعار تابه امروز پیش بینی شده بود. کیوت دارای سابقه ی دستگاه های اِمبد، دسکتاپ و موبایل و ساخت و توسعه اپلیکیشن های کاربردی با روش بهتر و ساده تر در تمامی پلتفرم ها می باشد. این احتمال وجود دارد که حتی استفاده از قابلیت های نرم افزاری کافی نیست. همچنین لازم است برای افزایش بهره وری از برنامه نویسان خبره ++C جهت توسعه بهتر استفاده شود.با استفاده از Qt رابط های برنامه نویسی به طور گسترده و مشهوری مستند سازی شده اند. بنابراین توسعه دهندگان ++C سازنده تر و مفید تر از قبل هستند. همچنین Qt زبان اعلانی با نام QML را جهت سهولت کار در طراحی فراهم کرده است، و رشد اینکه تعداد کثیری از مردم که می خواهند فراتر از توسعه دهندگان سی پلاس پلاس در توسعه دستگاه ها قدم بگذارند ایجاب شده است. در حال حاضر میلیون ها توسعه دهنده با Qt در جهان آشنا هستند که روز به روز برای به دست گرفتن آن میکوشند. با وجود زبان QML، مشکل اینگونه حل شده است تا بدون داشتن مهارت های بسیار بالا از ++C توسعه دهندگان بتوانند در زمینه رابط کاربری تیم خود را مدیریت کنند. البته برای ساخت هسته نرم افزار های دستگاه های تعبیه شده نیاز به ++C امریست ضروری. اما چیز دیگری می تواند کمک بهتری برای توسعه در اختیار قرار دهد. استفاده از Qt که اجازه می دهد هر دو نوع توسعه دهندگان غیر ++C و متخصصین ++C عملیاتی را که می خواهند بر روی دستگاه ها توسعه دهند فراهم می کند. و این اجازه می دهد توسعه دهندگان ++C تمرکز بهتری در تمامی زمینه ها داشته باشند.

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

مقدمه در دنیای برنامه‌نویسی، نوع جوابی که برای سوالات فنی خود می‌گیرید، هر چقدر که به سختی جواب دادن سوال بستگی دارد، همانقدر هم به روش پرسیدن شما بستگی دارد. با مطالعه‌ی این راهنما قادر خواهید بود طوری سوال کنید که به احتمال بیشتری جواب رضایت بخشی دریافت کنید. هدف ما از این سند در مرجع برنامه نویسی ایران، این است که فرهنگ مکاتبه و رسیدگی به مشکلات همدیگر را در زمینه‌های مرتبط افزایش و بهینه سازی کنیم. بنابراین، امروزه که برنامه‌نویسی بیش از پیش گسترده شده، می‌توانید از وجود افراد با‌تجربه استفاده کنید و جواب‌های خوبی دریافت کنید. با این حال حتی اگر افراد با‌تجربه هم برای پرسیدن سوال روش‌های توصیه شده در این راهنما را به کار گیرند جواب‌های مفید‌تری دریافت می‌کنند. اولین چیزی که باید درک کنیم این است که افراد با‌تجربه سوال های سخت و طولانی را دوست دارند که به خوبی ذهن را درگیر می‌کند. اگر به ما یک سوال جالب توجه بدهید که به آن فکر کنیم از شما سپاس‌گزار خواهیم شد. سوالات خوب محرک ذهن بوده و یک هدیه هستند. سوالات خوب به ما کمک میکنند تا فهم خود را توسعه دهیم و عموماً باعث آشکار شدن مشکلاتی میشود که ممکن است ما ندانیم یا به آنها توجهی نکرده باشیم. در میان افراد با‌تجربه یک سوال خوب یک چالش مهیج است. با این وجود بسیاری از تازه‌کار ها گمان میکنند که افراد با‌تجربه در مقابل سوالات ساده با دشمنی و تکبر برخورد می‌کنند و به نظر می‌رسد که واکنش گستاخانه‌ای با افراد تازه‌کار و ناآگاه دارند. اما به هیچ وجه این‌طور نیست! چیزی که بدون شرمندگی باید بگوییم، خصومت با افرادی است که ظاهراً تمایلی به تفکر در موضوع ندارند و جواب دادن به سوالشان را به نوعی وظیفه‌ی افراد با تجربه می‌دانند. از دید افراد با‌تجربه چنین افرادی باعث هدر رفتن وقت می‌شوند پس وقت خود را صَرف جواب دادن به سوالات بهتر میکنند. همچین افراد با‌تجربه بسیار داوطلب هستند و در زمان‌هایی که مشغول نباشند به پاسخ دادن به سوالات می‌پردازند. در آن مواقع غرق سوالات هستند. پس بدون ترس سوالات را فیلتر می‌کنند و ترجیح می‌دهند که به سوالاتِ بهتر جواب دهند. نوع رفتار شما شایستگی شما را برای دریافت جواب نشان می‌دهد. افراد شایسته زیرک، اندیشمند، هشیار و علاقمند به شرکت فعالانه در توسعهٔ یک راه‌حل هستند. بهترین راه برای گرفتن یک جواب سریع و خوب اینست که آن را مانند یک شخص زرنگ و مطمئن بپرسید، شخصی که واقعاً نیاز به کمک در یک مشکل خاص دارد. قبل از این که سوال کنید قبل از پرسیدن یک سوال فنی از طریق ایمیل، شبکه اجتماعی یا انجمن یک وبسایت، این کار‌ها را انجام دهید: سعی کنید جواب خود را با جستجو در ویکی‌پدیا و یا در قسمت‌های ویکی سایت مربوطه پیدا کنید. سعی کنید جواب خود را با جستجو در آرشیو انجمنی که می‌خواهید بفرسیتد، پیدا کنید. سعی کنید جواب خود را با جستجو در وب پیدا کنید. سعی کنید جواب خود را با خواندن manual (راهنما) پیدا کنید. سعی کنید جواب خود را با خواندن FAQ (سوالات متداول) پیدا کنید. سعی کنید جواب خود را از طریق بازبینی یا آزمایش پیدا کنید. سعی کنید جواب خود را با پرسیدن از یک دوست باتجربه پیدا کنید. اگر یک برنامه‌نویس هستید، سعی کنید جواب خود را با خواندن کدمنبع پیدا کنید. از فنونی استفاده کنید. برای مثال متن پیغام ارور را در گوگل جستجو کنید. حتی اگر به نتیجه ای نرسید، گفتن اینکه «من عبارت زیر را گوگل کردم، اما چیز امیدوار کننده‌ای پیدا نکردم» چیز خوبی برای یک گروه پستی یا خبری است، حداقل به این دلیل که مشخص می‌شود جستجو کمکی نمی‌کند. وقت بگذارید. انتظار نداشته باشد که بتوانید مشکل پیچیدهٔ خود را با چند ثانیه گوگل کردن حل کنید. FAQ ها را بخوانید و بفهمید، آرام و باتمرکز بنشنید و کمی در مورد مشکل خود فکر و گمانه‌زنی کنید. به یکباره تمام سوالات خود را ارسال نکنید فقط به خاطر اینکه اولین جستجوی شما به هیچ جوابی نرسید (یا به جواب‌های زیادی رسید). سوال خود را آماده کنید. به آن فکر کنید. سوالات شتاب‌زده به جواب‌های شتاب‌زده منجر خواهد شد، یا اصلاً به هیچ جوابی نمی‌رسد. هر چه بیشتر این را نشان دهید که برای حل مسئلهٔ خود قبل از درخواست کمک، فکر و تلاش کرده‌اید، همانقدر احتمال بیشتری خواهد رفت که واقعاً به شما کمک کنند. از پرسیدن سوال اشتباه، اجتناب کنید. اگر سوالی بپرسید که بر اساس فرض‌های ناقص و اشتباه است، یک فرد با تجربه ممکن است با این تصور که «یک سوال احمقانه است...» بخواهد به شما یک جواب لفظی و بی‌فایده بدهد، و به امید اینکه شما درس بگیرید از تجربهٔ گرفتن آنچه پرسیدید، نه آنچه مورد نیاز شما بود. ما وقتی می‌توانید به جواب برسید که یک سوال قابل توجه و برانگیزندهٔ ذهن بپرسید، سوالی که بطور ضمنی باعث کمک به تجربهٔ جامعه می‌شود، نه آنکه فقط بصورت انفعالی خواستار دانش از دیگران باشید. از طرف دیگر، روشن ساختن اینکه شما توانایی و تمایل کمک در پروسهٔ حل مسئله را دارید، شروع بسیار خوبی است. «آیا کسی می‌خواهد منبعی معرفی کند؟»، «مثال من چه چیز کم دارد؟»، و «چه وبسایتی را بهتر است بررسی کنم» به احتمال بیشتری جواب خواهند گرفت نسبت به این سوال که «لطفاً روش دقیق کاری که باید انجام دهم را بنویسید.». چون [در حالت اول] شما این را روشن می‌سازید که واقعاً راغب به تکمیل پروسه [ی حل مشکل] هستید اگر شخصی فقط مسیر صحیح را به شما نشان دهد. وقتی سوال می‌کنید: انجمن خود را به دقت انتخاب کنید به این حساس باشید که کجا سوال خود را مطرح می‌کنید. شما احتمالاً نادیده گرفته خواهید شد اگر: سوال شما دارای عنوان مناسب نباشد. یک سوال بسیار ابتدایی را در انجمنی پست کنید که انتظار سوالات فنی پیشرفته را دارند. یا بالعکس. یک سوال مشترک را در چند گروه خبری پست کنید. یک ایمیل شخصی به کسی بفرستید که نه سابقه آشنایی با شما دارد، و نه شخصاً مسئول حل مشکل شماست. افراد با تجربه سوالاتی که بیجا در مکان خاصی پست شود را پاک می‌کنند تا کانالهای ارتباطی‌شان را از غرق شدن در بی‌ربطی حفظ کند. شما نمی‌خواهید این اتفاق برایتان بیفتد؛ بنابراین اولین قدم این است که انجمن درست را انتخاب کنید. باز هم، گوگل و سایر روشهای جستجوی وب، دوست شما هستند. از آنها استفاده کنید. رها کردن یک ایمیل به سوی شخص یا انجمنی که با آن آشنا نیستید، در بهترین حالت یک ریسک است. در مورد اینکه آیا سوال شما مورد استقبال واقع می‌شود یا نه، حدس‌های خوشبینانه نزنید. اگر مطمئن نیستید آن را جای دیگری بفرستید یا اینکه از فرستادن آن خودداری کنید. به یکباره سوال خود را به همه‌ی کانال های کمک‌رسانی ارسال نکنید، این کار مانند فریاد زدن است و افراد را عصبانی می‌کند. به آرامی از میان آنها گام بردارید. عموماً سوالاتی که در یک انجمن عمومی و درست (بجا) پرسیده شوند، احتمال اینکه جواب مفید بگیرند بیشتر است تا آنهایی که در جای خصوصی پرسیده می‌شوند. چندین دلیل برای این وجود دارد. یک دلیل ساده، مقدار منابع پاسخگو است. یکی دیگر تعداد بازدیدکنندگان است؛ افراد با‌تجربه ترجیح می‌دهند به سوالاتی جواب دهند که افراد بیشتری را آموزش دهد، تا سوالاتی که فقط به درد افراد کمی بخورد. به وضوح، برنامه‌نویسان چیره‌دست و سازندگان نرم‌افزارهای محبوب، همواره بسیار بیشتر از توان پاسخ‌گویی‌شان، پیغام‌های انبوه و بی‌هدف دریافت می‌کنند. شما با اضافه شدن به این سیل، یکی از آن موارد بسیار زیاد هستید. از عناوین پرمعنا و دارای موضوع مشخص، استفاده کنید در لیست‌های پستی، گروه‌های خبری یا انجمن‌های وب، عنوانِ موضوع، فرصت طلایی شماست تا با حدود ۵۰ کاراکتر یا کمتر، توجه متخصصانِ قابل را جلب کنید. با عناوینی مثل «لطفاً به من کمک کنید»، آن را هدر ندهید (پیغام‌هایی با این‌گونه عناوین به راحتی دور انداخته می‌شوند). سعی نکنید با عمق اضطراب خود، افراد با تجربه را تحت تأثیر قرار دهید؛ در عوض، از آن فضا برای یک توصیف بسیار مختصر از مشکل خود استفاده کنید. نامطلوب: کمک! کتابخانه X روی لپ‌تاپ من درست کار نمی‌کند! هوشمندانه: با استفاده از امکانY از کتاب‌خانه X برنامه من کار نمی‌کند! هوشمندانه تر: با استفاده از امکان Y در کتاب‌خانه X نسخه 5.8 برنامه من کرش (Crash) می‌کند. تصور کنید که به یک لیست از سوالات یک آرشیو نگاه می‌کنید، که فقط خطوط عنوان‌ها نمایش داده می‌شوند. عنوان پست خود را طوری انتخاب کنید که بخوبی سوال شما را منعکس کنید، تا شخص بعدی که آرشیو را جستجو می‌کند، بتواند دنبال آن ریسمان (thread) را بگیرد و به یک جواب برسد، بجای اینکه دوباره آن سوال را پست کند. رسیدن یک سوال در یک پاسخ، به خودی خود مورد شک است، چون آن فقط توسط افرادی دیده خواهد شد که این ریسمان را دنبال می‌کنند. پس یک ریسمان (تاپیک) جدید را آغاز کنید، مگر اینکه مطمئنید می‌خواهید فقط از افرادی بپرسید که در حال حاضر در این ریسمان فعال هستند. پاسخ دادن را آسان کنید پایان دادن سوال با این عبارت که «لطفاً پاسخ خو را به ... بفرستید»، جواب گرفتن شما را کاملاً بعید می‌سازد. بصورت واضح، از لحاظ دستوری صحیح، و با املای صحیح بنویسید مهم است که سوال خود را واضح و خوب بیان کنید. قبل از ارسال سوال خود یکبار متن سوالتان را بررسی و سعی خود را بکنید تا زبان (بیان) خود را بهبود دهید (صیقل دهید). لازم نیست که رسمی و سنگین باشد. در واقع افراد با تجربه به آن طرز بیانی بها میدهند که غیر رسمی، عامیانه، شوخ‌طبعانه و همراه با دقت و ظرافت باشد. اما باید دقیق باشد؛ باید نشانه‌هایی از اینکه که شما اندیشه و توجه می‌کنید را داشته باشد. این نکته بسیار مهم است که به زبان رسمی آن کانال ارتباطی سوال خود را ارسال کنید. برای مثال اگر در انجمنی که زبان رسمی آن فارسی است سوال خود را به زبان انگلیسی (یا فینگلیش) بنویسید سوال شما معمولا یا پاک خواهد شد و یا نادیده گرفته می‌شود. اگر دارید سوال خود را در انجمنی می‌پرسید که از زبان بومی شما استفاده نمی‌کند، شما یک میزان محدودی از خطاهای املایی و دستوری خواهید داشت، اما از روی تنبلی دچار خطاهای بیش از حد نشوید (بله، افراد معمولاً می‌توانند آن تفاوت را تشخیص دهند). همینطور اگر نمی‌دانید که شخص پاسخگو چه زبانی دارد، به انگلیسی بنویسید. افراد با‌تجربه مشغول، سوالات با زبانی که نمی‌فهمند را نادیده می‌گیرند، و انگلیسی زبان کاری اینترنت است. با نوشتن به زبان انگلیسی، این احتمال را که سوالتان بدون خوانده شدن پاک شود، به حداقل می‌رسانید. سوال خود را در قالب‌های استاندارد و در دسترس مطرح کنید نامه خود را به صورت پاراگراف‌هایی که از خطوط به هم پیچیده شده تشکیل شده‌اند، نفرستید. این کار، پاسخ گویی به قسمت‌های مختلف نوشته شما را دشوار می‌کند. هرگز تصور نکنید که مخاطبین شما قادر به خواند فایل‌های اختصاصی مانند Microsoft word یا Excel هستند. افراد مختلف از سیستم عامل‌های مختلف و برنامه‌های متفاوتی برای ویرایش متن استفاده می‌کنند پس بهترین گزینه این است که فایل خود را به صورت متنی ارسال کنید. در صفحات گفتگو، از اشکال خندان (Smile) و امکانات HTML استفاده نکنید. یکی دو تا از این اشکال ایرادی ندارد. اما در صورت استفاده بیش از حد. بهای سوال شما را کاهش می‌دهد و احتمال نادیده گرفته شدن سوال شما افزایش پیدا می‌کند. اگر شما از یک پردازش‌گر ایمیل با صورت گرافیکی کاربری مانند MS، Outlook، Netscape، Messenger و یا از این‌گونه‌ها استفاده می‌کنید، آگاه باشید که در صورتی که از تنظیمات پیش‌فرض آن استفاده می‌کنید، ممکن است این قوانین نقض شوند. بیشتر این پردازشگرها دارای یک دستور در فهرست خود به نام view source هستند از این گزینه در پوشه نامه‌های فرستاده خود استفاده کنید و فرستادن نوشته ساده (plain tent) بدون ضمایم غیر ضروری را بررسی کنید. درباره مشکل خود دقیق و آگاه باشید نشانه‌های مشکل ایجاد شده یا bug ها را به دقت و روشنی شرح دهید. محیطی که در آن این مشکل ایجاد می‌شود را شرح دهید. (سیستم عامل، کاربرد و ...) شرکت فروشنده و مدل آنرا هم معرفی کنید مثلاً (Fedora Coret یا Slackware 91 و ...). مطالعاتی که بر روی این مشکل انجام داده‌اید را شرح دهید. مراحل تشخیص مشکل و رفع آنرا که انجام داده‌اید، قبل از طرح سوال، شرح دهید. هرگونه تغییر در سخت‌افزار یا نرم‌افزار که اخیراً انجام شده است را شرح دهید. تلاش کنید تا به سوالاتی که پیش‌بینی می‌کنید از شما پرسیده شوند، پیش‌تر پاسخ دهید. حجم مطالب دلیلی بر دقیق بودن آن نیست باید دقیق و آموزنده بنویسید. این هدف با نوشتن حجم زیادی از داده‌ها و کدها در نامه تقاضای کمک محقق نمی‌شود. اگر یک مشکل بزرگ و پیچیده دارید، سعی کنید تا آنرا تا حد ممکن خلاصه و مرتب ارائه کنید. این امر حداقل سه فایده دارد. اول اینکه معلوم شود که شما برای خلاصه کردن سؤال خود تلاش کرده‌اید یا تمایل بیشتری برای پاسخ به شما وجود خواهد داشت. دوم اینکه با خلاصه‌سازی پاسخ مفیدتری هم خواهید گرفت؛ و سوم اینکه در حین خلاصه کردن و پیرایش گزارش خود ممکن است بتوانید مشکل را حل کنید یا راه حل کوتاه‌تری برای آن پیدا کنید. بدون اطمینان ادعای یافتن یک bug را نکنید! هنگامی که با یک نرم‌افزار به مشکل برخوردید، بدون اطمینان کامل ادعای یافتن یک bug جدید را مطرح نکنید. راهنمایی: تا هنگامی که با یک ضمیمه به کد منبع نتوانید مشکل را برطرف کنید یا با آزمایش رگرسیون با ورژن قبلی که نشان دهنده یک رفتار نادرست باشد، شما نباید مطمئن شوید. این امر در مورد وب سایت‌ها و مدارک هم صدق می‌کند سندی را به عنوان bug یافتید، باید متنی را جایگزین آن کنید یادآوری می‌شود که کاربران بسیاری هستند که مشکل شما را تجربه نکرده‌اند. همچنین شما با خواندن مطالب و وب سایت‌های مرتبط، در مورد آن نرم‌افزار آموزش دیده‌اید در غیر این صورت شما کاری را اشتباه انجام می‌دهید و نه نرم‌افزار. افرادی که یک نرم‌افزار را تهیه می‌کنند، تلاش می‌کنند تا آن نرم‌افزار حداکثر کارایی مطلوب را داشته باشد. اگر شما ادعا کنید که یک bug در آن یافته‌اید، در واقع کامل بودن کار آنها را زیر سؤال برده‌اید و این باعث رنجاندن آنهان می‌شود، حتی اگر حق با شما باشد. به خصوص ذکر کلمه bug در عنوان نامه، کار سیاست مدارانه‌ای نیست. وقتی که سوال خود را مطرح می‌کنید، بهتر است فرض کنید که شما کار اشتباهی را انجام می‌دهید، حتی اگر مطمئن باشید که یک bug واقعی را یافته‌اید. اگر واقعاً این طور باشد، در مورد آن در پاسخ‌ها خواهید شنید. با این کار نگهدارنده‌های نرم‌افزار از شما عذرخواهی خواهند کرد، همچنین اگر شما اشتباه کرده باشید، باید از آنها عذرخواهی کنید. به جای حدس‌های خود نشانه‌های مشکل را شرح دهید نوشتن در مورد اینکه خودتان علت مشکل پیش آمده را چه می‌دانید، مفید نیست (اگر فرضیات شما به‌کلی اشتباه باشد آیا با دیگران مشورت می‌کنید؟). لذا سعی کنید که به دوست‌داران کامپیوتر از علائم و نشانه‌های اولیه مشکل موجود بگویید و نه از فرضیات و تئوری‌های خود. بگذارید آنها خود تفسیر کنند و مشکل را تشخیص دهند اگر احساس می‌کنید که ذکر کردن حدس خودتان می‌تواند مهم باشد، آنرا روشن و تحت عنوان حدس خودتان بیان کنید و همچنین ذکر کنیدن که چرا این پاسخ نمی‌تواند جوابگوی مسئله باشد. هدف را مشخص کنید، نه مرحله اگر به دنبال این هستید که بدانید چطور باید کاری را انجام دهید (مثل گزارش کردن یک اشکال یا bug )، با شرح دادن هدف خود شروع کنید. بعد از آن فقط برخی از مراحل خاص که برای رسیدن به آن طی کردید و موفق نشدید را شرح دهید. اغلب، افرادی که به کمک تکنیکی نیاز دارند، هدف بلند مرتبه‌ای را در ذهن می‌پرورانند و در راهی که فکر می‌کنند تنها راه رسیدن به هدف است گمراه می‌شوند. آنها برای کمک گرفتن مرحله به مرحله می‌آیند اما نمی‌دانند که مسیر اشتباه است تلاش قابل توجهی برای گذر از این مرحله مورد نیاز است. سوال نامطلوب: چگونه می‌توان در برنامه FooDraw مقادیر RGB رنگ را بر مبنای شانزده‌تایی انتخاب کرد؟ سوال هوشمندانه: من تلاش می‌کنم که جدول رنگ‌ها را روی یک تصویر با مقادیر انتخابی خودم قرار دهم. در حال حاضر تنها راهی که به نظرم می‌رسد اینست که هر ردیف از جدول را اصلاح کنم اما نمی‌توانم در برنامه FooDraw رنگ‌ها را بر مبنای مقادیر RGB شانزده‌تایی انتخاب کنم. سوال دوم هوشمندانه بود. جواب این سوال ابزار بهتری برای آن کار را پیشنهاد می‌دهد. سوال را صریح مطرح کنید برای سوال‌هایی که انتهای مشخصی ندارد، بازه زمانی محدودی برای پاسخگویی به آنها در نظر گرفته نمی‌شود. کسانی که می‌خواهند پاسخ‌های مفیدی به شما بدهند، مشغول‌ترین افراد هستند. (چون در اغلب کارها به تنهایی کار می‌کنند). این گونه افراد نسبت به سوال‌هایی با بازه زمانی نامحدود حساسیت دارند و تمایل چندانی به پاسخ‌گویی به آنها ندارند. شما هنگامی که یک پاسخ مفید دریافت می‌کنید که از پاسخگویی خود در مورد چیزی که می‌خواهید به‌طور صریح پرسیده باشید (از اشاره‌گر استفاده کند، که بفرستید، پیوست را بررسی کنید یا هر چیز دیگر). این کار تلاش پاسخگو را بر روی هدف شما متمرکز می‌کند و به طور ضمنی حدی از نظر زمانی برای پاسخگویی و صرف انرژی برای کمک به شما ایجاد می‌کند. این کار خوبی است. برای درک دنیایی که متخصصین در آن زندگی می‌کنند، به مهارت به عنوان یک منبع و زمان فراوان برای پاسخگویی به یک مورد کمیاب فکر کنید. هر چه زمان کمتری را برای پاسخگویی به سوال خود به طور ضمنی در نظر بگیرید، احتمال اینکه جواب واقعاً مناسب از جانب یک فرد خبره و پرمشغله دریافت کنید، بیشتر می‌شود بنابراین بهتر است که برای سوال خود قالبی در نظر بگیرید که زمان مورد نیاز به پاسخگویی به آن را از جانب یک فرد خبره به حداقل برساند. اما این کار اغلب مشابه ساده‌سازی یک سوال نیست. به عنوان مثال، ممکن است برای شرح مناسبی از X یک راهنمایی بکنید؟ معمولاً سوال هوشمندانه‌تری است نسبت به اینکه ممکن است لطفاً X را توضیح دهید! اگر شما یک کد نادرست دارید، بهتر است در مورد اینکه چه اشکالی دارد بپرسید تا اینکه درخواست کنید کسی آنرا اصلاح کند. سوالهای بی‌معنی را حذف کنید از به پایان رساندن درخواست سوال خود با جملات بی‌مفهومی مانند کسی می‌تواند به من کمک کند؟ یا آیا جوابی وجود دارد؟ پرهیز کنید. اولاً، اگر شرح خود را تا نیمه نوشته بودید، این گونه سوال‌ها زائد هستند. دوماً، به دلیل زائد بودن آنها کاربران آنها را آزاردهنده تلقی می‌کنند و احتمال دارد که جواب‌هایی بی عیب و نقص ولی بی اعتنا مانند بله، به شما می‌توان کمک کرد. یا خیر، هیچ کمکی نمی‌توان کرد به شما بدهند. به طور کلی، از سوالهای آری یا خیر باید اجتناب شود مگر اینکه تنها جواب بله یا خیر برای شما کافی باشد. سوال خود را با کلمه «فوری» نشانه‌دار نکنید، حتی اگر برای شما اینگونه باشد: این مشکل شماست، نه دیگران. اظهار ضرورت کردن نتیجه معکوس می‌دهد. بیشتر کاربران به راحتی اینگونه سوال‌ها را که با خودخواهی و گستاخی درخواست توجه فوری و ویژه می‌کنند را حذف می‌کنند. تنها یک شبه استثناء وجود دارد. اگر شما در یک محل با مرتبه بالا و با یک نرم‌افزار کار می‌کنید و از نظر زمانی تحت فشار هستید، گفتن مودبانه محدودیت زمانی خود می‌تواند مؤثر باشد تا دیگران را به پاسخ دادن به شما ترغیب کند. البته این کار ریسک بالایی دارد، چون معیار جالب بودن مسائل از نظر کاربران دیگر با شما متفاوت است. به عنوان مثال فرستادن نامه از یک ایستگاه فضایی بین‌المللی قانع کننده است اما از جانب یک انسان با احساس خوب و مهربان یا یک سیاستمدار خیر. در واقع، نوشتن کلمه «فوری» باعث می‌شود که از سوال شما اجتناب و دوری شود حتی اگر از نظر آنها مهم باشد. اگر فکر می‌کنید که این امری مبهم است، دوباره این مطالب را بخوانید تا کاملاً آنرا درک کنید، قبل از آنکه نوشته‌ای را به جایی بفرستید. ادب و احترام را رعایت کنید مؤدب باشید. از جملاتی مانند «لطفاً» و «با تشکر از توجه شما» یا «ممنون از ملاحظه شما» استفاده کنید. به طور واضح بیان کنید که شما اینکه دیگران وقت خود را برای کمک به شما رایگان صرف می‌کنند، تحسین کنید. صادق بودن، به اندازه واضح، دقیق، با دستور زبان صحیح و مشروح بودن و پرهیز از قالب‌های مالکانه، مهم نیست و حتی جایگزین آنها هم نمی‌تواند باشد. کاربران بطور کلی علاقه دارند که گزارش‌های دقیق تکنیکی از bug ها و ایرادها را هر چند بی ادبانه دریافت کنند تا نوشته‌های مؤدب ولی ابهام‌آمیز. (اگر این امر برای شما مبهم است، به یاد داشته باشید که سوال‌ها را با چیزی که توسط آن می‌توان یاد گرفت ارزش‌گذاری می‌کنند). به هر حال اگر مشکلات تکنیکی خود را ردیف کنید، مؤدب بودن شانس شما را برای دریافت پاسخ مفید افزایش می‌دهد. باید ذکر شود که تنها مخالفتی که از سوی کاربران قدیمی نسبت به این نوشته دریافت کرده‌ایم، در رابطه با توصیه‌های قبلی ما برای تشکر پیشاپیش است. برخی از کاربران احساس می‌کنند که این دلالتی به منظوری دارد و نه تشکر. توصیه ما اینست که هم پیشاپیش تشکر کنید و هم بعد از پاسخ‌گویی و یا ادب و احترام را به روشهای دیگری بیان کنید قبلاً با جملاتی مثل: «با تشکر از توجه شما» یا «ممنون از ملاحظه شما». روش حل را با یادداشت مختصری پاسخ دهید بعد از اینکه مسئله حل شد، یادداشتی به همه کسانی که به شما کمک کرده‌اند بفرستید، آنها را از نحوه‌ی حل مطلع کنید؛ و باز هم از یاری آنها تشکر کنید. پاسخ شما نباید طولانی و شامل جملاتی ساده مثل: «ایراد از کابل شبکه بود، با تشکر از همه» باشد. حتی اگر پاسخ ندهید، بهتر از این جملات است. پاسخ کوتاه و خلاصه‌ای شیرین بهتر است از یک مقاله طولانی مگر اینکه عمق تکنیکی مسئله زیاد باشد. ذکر کنید که چه عملی مشکل را حل کرد اما لزومی ندارد که تمام مراحل حل مشکل را گزارش کنید. برای برخی از مسائل مناسب است که خلاصه‌ای از مراحل رفع مشکل را گزارش کنید. وضعیت نهایی مسئله خود را شرح دهید. توضیح دهید که چه روشی شما را به حل رساند و بعد از آن به داده‌هایی که جواب نمی‌رسد اشاره کنید. روشهای اشتباه را باید بعد از جواب صحیح و دیگر مطالب خلاصه بیاورید تا اینکه خلاصه شما تبدیل به یک داستان کارآگاهی نشود. از افرادی که به شما کمک کردند نام ببرید، با این کار با آنها دوست هم می‌شوید. در نهایت، این گونه خلاصه نویسی به تمام کسانی که کمک کرده‌اند، احساس رضایت‌مندی و نزدیکی به مسئله می‌دهد و این کم ارزش نیست. اگر شما یک تکنسین یا فرد باتجربه نیستید، مطمئن باشید که این احساس برای راهنماها و متخصصینی که از آنها کمک گرفته‌اید، بسیار مهم است. اگر نفهمیدید... اگر جواب را نفهمیدید، فوراً تقاضای روشن کردن پاسخ نکنید. از همان اندازه‎هایی که برای پاسخ اولیه خودتان (دستورالعمل‎ها ( FAQS)، وب و دوستان ماهر) برای فهمیدن جواب استفاده کنید. سپس اگر باز هم نیاز به شفاف سازی نشان دهید که چه چیزی یادگرفته‎اید. برای مثال تصور کنید که من به شما می‎گویم: "به‎نظر می‎رسد که شما Zentry گرفته شده‎ای دارید، باید آنرا تمیز کنید." در این صورت یک جواب نامناسب این خواهد بود: « Zentry چیست؟» و یک جواب خوب این خواهد بود "بسیار خوب، من صفحه اصلی را خواندم و به Zentry ها تحت عنوان سوئیچ‎های –Z و –P اشاره شده است اما هیچ یک از تمیز کردن Zentry چیزی نگفته‎اند. آیا اینها درست است یا من نکته‎ای را متوجه نشده‎ام؟" اخلاق حرفه ای داشته باشید با توجه به راه‎های مفصلی که در این‎جا گفته شد یا راه‎های مشابه بعید است که در راه‌های ارتباطی با افراد باتجربه اشتباه کنید. به‎طور دقیقی با جملات متفاوت به شما گفتیم که چگونه می‎توان اشتباه کرد. اگر چنین اتفاقی افتاد بدترین کار اینست که از این تجربه خود ناله کنید، ادعا کنید که شفاهاً مورد توهین قرار گرفته‎اید، تقاضای عذرخواهی کنید، نقستان را حبس کنید، به شکایت کردن تهدید کنید، از افراد شکایت کنید و غیره. در عوض پیش بروید. این امری طبیعی است. درواقع مناسب و سالم است. گاهی اوقات افراد بدون هیچ دلیل روشنی شخصاً شما را مورد حمله قرار می‎دهند حتی اگر شما اشتباهی نکرده باشید (یا فقط در ذهن آنها دچار اشتباه شده‎اید) در این موارد، شکایت کردن روشی واقعاً اشتباه است. این افرادِ متجاوز، نادان هم هستند که بدون هیچ دلیلی، خود را با تجربه می‎دانند یا با آزمایش‎های روان‎شناسی می‎خواهند بدانند که اشتباه کرده‎اید یا خیر. خوانندگان دیگر هم آنها را نادیده می‎گیرند و یا با روش خودشان با آنها برخورد می‎کنند رفتار این‎گونه افراد خود آنها را دچار مشکل می‎کند که به شما ربطی ندارد. اجازه ندهید که داخل این‎گونه بحث‎ها به دام بیفتید. بعد از اینکه بررسی کردید که آیا آنها واقعاً توهین هستند و نه اشاره‎ای به اشتباه شما و نه اشاره‎ای به اشتباه شما و نه اشاره‎ای زیرکانه به جواب واقعی سوال شما اغلب توهین‎ها نادیده گرفته می‎شوند. به اطلاعات موجود در فایل های ارسالی و ضمیمه توجه کنید در بسیاری از مواقع ممکن است سوال شما همراه با فایل (یا فایل های) ضمیمه‌ای باشد که مشکل را دقیق‌تر به پاسخ دهند‌گان شرح میدهد. حتما قبل از ارسال فایل ضمیمه به موارد زیر توجه کنید: فایل ارسالی حاوی اطلاعات شخصی افراد نباشد. این موارد حریم شخصی افراد را نقض میکند و ممنوع میباشد. در صورتی که سوال شما مربوط به نحوه‌ی نمایش آن اطلاعات است میتوانید با ابزار ویرایش تصویر یا فایل، اطلاعات شخصی را حذف کنید.

مقدمه نقد و بررسی‌ و ارسال نظرات کارشناسی سایت مرجع آی او استریم با هدف شناساندن هرچه بیشتر و بهتر زبان‌ها و فناوری‌های برنامه نویسی به مخاطب و همچنین کمک به تصمیم‌گیری در رابطه با نحوه‌ٔ شروع برنامه نویسی و کسب تجربه می‌باشد که در کنار آن علاوه بر این هدف ما شناساندن متخصصین به جامعه استارتاپی کشور است. توضیحات کلی در نقد و بررسی‌ها آی او استریم، پیش از خواندن متن سوالات و پاسخ‌ها می‌توانید به طور کاملا خلاصه با نکات مثبت و منفی موضوعات مطرح شده و همچنین نظر کلی سایت در مورد زبان‌های برنامه نویسی، استارتاپ‌ها و ... آشنا شوید. سیستم اعتبار این قابلیت را فراهم می سازد تا کاربران از طریق واکنش هایی که دیگران به مطالب آن ها می دهند، امتیاز کسب نمایند. امتیاز کل کاربر که از سرتاسر سایت کسب کرده است در نمایه وی نمایش داده می‌شود که موجب نمایش اعتبار واقعی آن در مرجع می‌شود. امتیازها امتیازهای مرجع از کمترین امتیاز ممکن (۲۰-) آغاز شده و به بهترین امتیاز ممکن (۲۰+) ختم می‌شود.

با سلام و احترام، دوستان از اینکه بستری برای دوره هم بودن جامعه برنامه نویسان استارتاپی ایران ایجاد شده بسیار خوشحالیم! امیدواریم که وقتی این متن رو می‌خونین در نبرد همیشگی روزانه‌تون با باگ‌ها پیروز میدان بوده باشین. لطفا قبل از شروع، یه فنجان دمنوش، چایی یا قهوه بردارین و بعد ادامه‌ی متن رو بخونین. بله جدی گفتیم… همین الان برین اینکار رو بکنین… ما همین جا منتظرتون هستیم ? [چند دقیقه بعد] سلام دوباره. نوشیدنی خوبی به نظر میاد، بوش حتی از پشت اسکرین هم اینجا می‌رسه ? اگه تازه به عنوان مهمان وارد مرجع شدین می‌تونید در صورت تمایل ثبت نام کنید. دقت کنید که ثبت نام برای همگان رایگان هست اما بر اساس قوانین ذکر شده دسترسی‌ها به صورت کامل برای گروه‌های پیش فرض ثبت نام شده آزاد نیست. توجه داشته باشید که، برای دسترسی به گروه‌های برتر باید فعالیت‌های شما طبق شرایط ذکر شده تایید شود. در مرجع معرفی نام و نام خانوادگی بسیار مهم است! چرا که در معتبر سازی شما به عنوان یک متخصص قابل اعتماد بسیار مهم است. بنابراین بد نیست خودتون رو در بخش درباره من معرفی و نام نمایشی کاربری خودتون رو به صورت واقعی وارد کنید. #قوانین و شرایط عضویت و فعالیت

شما برنامه نویس هستید یا توسعه‌دهنده؟ آیا تا به حال فکر کرده‌اید که چه نوع عنوانی متناسب با مهارت‌های شماست؟ من یک (توسعه دهنده فول-استک هستم) من یک (برنامه‌نویس هستم) من یک (توسعه‌دهندهٔ وب هستم) من یک (توسعه‌دهندهٔ فرانت اند هستم) من یک (توسعه دهندهٔ iOS هستم) و عناوین بسیار زیاد من در آوردی دیگر که ممکن است منظور دقیق از مهارت‌های شما را به درستی مطرح نکنند! من می‌خوام در رابطه با اصطلاحاتی صحبت کنم که شاید بسیاری از علاقه‌مندان از استفادهٔ به جا از آن‌ها بی‌خبر هستند. داستان این مقاله از اینجا شروع می‌شه که امروزه عناوین متعددی در رشتهٔ مهندسی کامپیوتر به خصوص گرایش نرم‌افزار و (برنامه‌نویسی) به چشم می‌خوره که ممکنه باعث سردرگمی بشه. نکته اصلی اینجاست که ما به عنوان صاحب عنوان تخصصی خود باید بدانیم که دارای چه مهارت‌هایی هستیم و در دنیای فناوری تحت چه عنوانی باید خود را در زمینه تخصصی معرفی کنیم. تفاوت بین کدنویس، برنامه‌نویس و توسعه‌دهنده در این پست قصد داریم با اصطلاحاتی آشنا شویم که ممکن برای اکثر افراد غیرمتخصص و گاه متخصص نیز سوال باشد که این عنوان‌ها (کدنویس، برنامه نویس و توسعه‌دهنده) به چه کسانی با چه تخصص‌های گفته می‌شود. ما به عنوان صاحب “عنوان تخصص” خود باید بدانیم که دارای چه مهارت‌هایی هستیم و در دنیای فناوری تحت چه عنوانی باید خود را در زمینه تخصصی معرفی کنیم. در این مقاله تصمیم گرفتم تفاوت‌های بین کدنویس (Coder)، برنامه‌نویس (Programmer) و توسعه‌دهنده (Developer) را مشخص کنم. بنابراین به ترتیب عناوین هر یک از آن‌ها را توضیح و در رابطه با نکات مهم متمایز کنندهٔ آن‌ها اشاره خواهیم کرد. 1.کدنویس (Coder) کد نویس به کسی گفته می‌شود که می‌تواند بدون داشتن مهارت خاص یا حتی رشته مرتبط کدنویسی کند و نیاز به دانش تخصصی و واقعی علوم کامپیوتری ندارد. معمولاً کسانی که دارای تخصص دیگری هستند اما آشنا به منطق برنامه‌نویسی نیستند کُدِر می‌گویند. برای مثال تغییر دادن و یا ویرایش کد‌های از قبل نوشته شده و حتی ایجاد نمونه‌ای از کدهایی موجود به صورت (کپی) که می‌تواند نتیجه‌ای به صورت کار بر روی یک سیستم نرم‌افزاری بر روی وب مانند WordPress یا غیره شود که با کمی تغییرات بر اساس نیاز پروژه خود را به صورت نه چندان حرفه‌ای ایجاد و توسعه نمایند. اصطلاح درست این نوع اشخاص کُدر می‌باشد. 2.برنامه‌نویس (Programmer) برنامه‌نویس به کسی گفته می‌شود که توانایی و تخصص مرتبط با برنامه‌نویسی و علوم کامپیوتری را دارد. به عنوان مثال یک مهندس نرم‌افزار از شاخه مهندسی کامپیوتر که با منطق برنامه نویسی آشنا است برنامه نویس محسوب می‌شود. برنامه‌نویس می‌تواند برنامه‌ای را تحت یکی از زبان‌های برنامه‌نویسی که خود آن را ترجیح می‌دهد برنامه نویسی کند. برای مثال، کلاسی را طراحی و پیاده سازی کرده و توابع مورد نیاز خود را در آن ایجاد و توسعه دهد. برنامه‌نویس می‌داند در کجا باید از چه نوع دستورات و توابعی استفاده کند تا کدِ نهایی او نتیجه‌ای ایجاد کند که از آن انتظار می‌رود. یک برنامه‌نویس توانایی این را دارد که کُدهای نوشته شده توسط دیگر برنامه‌نویسان را بخواند، درک کند و حتی آن‌ها را ویرایش کند. توجه داشته باشید که یک برنامه‌نویس توانایی کنترل و مدیریت کردن بخش‌های بسیار پیچیدهٔ یک محصول را ندارد. برای مثال اگر قرار است پروژه‌ای را طراحی و توسعه نمایید برنامه‌نویس بخش بَک-اِند توانایی مدیریت بخش فرانت-اند (رابط‌کاربری) را ندارد و برعکس! بنابراین برنامه‌نویسان تنها کُدهایی را می‌نویسند که قرار است در بخش مورد نیاز عملیاتی را انجام دهند و کاری به این ندارند که طراحی رابط‌کاربری تحت چه نوع فناوری و زبانی در حل توسعه است و یا ارتباط با پایگاه داده چگونه صورت می‌گیرد چرا که برنامه‌نویسان مرتبط با آن بخش‌ها با استفاده از مهارت های تخصصی خود در آن بخش آن را هندل خواهند کرد. برنامه‌نویسان معمولاً تیم‌های توسعه یک محصول را ایجاد می‌کنند و همگی آن‌ها وابسته یکدیگر هستند بنابراین اگر برنامه‌نویس واحد بک اند شما نتواند به موقع کدهای مورد نیاز بخش فرانت‌اند شما را آماده و تحویل دهد پروژه شما در زمان تعیین شده به نتیجه مطلوبی نخواهد رسید. 3.توسعه دهنده (Developer) در رابطه با توسعه‌دهنده باید به این توجه داشته باشید که توسعه‌دهنده به تنهایی عنوان نمی‌شود. بنابراین توسعه‌دهنده به صورت‌های مختلفی وجود دارند (توسعه‌دهنده وب، توسعه‌دهندهٔ نرم‌افزار، توسعه‌دهندهٔ موبایل که در رابطه با نوع پلتفرم باز متفاوت هستند؛ توسعه دهنده رابط کاربری، توسعه‌دهندهٔ تجربه کاربری و در نهایت توسعه دهنده فول-استک). توسعه‌دهنده کسی است که علاوه بر برنامه‌نویس بودن مهارت و دانش کافی در لایه‌های مختلف پروژه در اختیار داشته باشد که متناسب با نوع تخصص نیز متفاوت است. توسعه‌دهنده کسی است که می‌تواند بر اساس نوع پروژه وظایف خاصی را در اختیار بگیرد به عنوان مثال اگر به صورت تیمی بر روی یک پروژه کار می‌کنید که شامل برنامه نویس هایی است که هر کدام بخشی از پروژه را برنامه‌نویسی می‌کنند کافی است یک توسعه‌دهنده داشته باشید تا تمامی کد‌های شما را آنالیز، اشکال زدائی و بررسی کند و در نهایت آن‌ها را با یکدیگر ارتباط داده و تبدیل به یک پروژه قابل استفاده نماید. چرا که توسعه‌دهنده دانش مورد نیاز در لایه‌های مختلف را دارد و می‌داند بخش‌های مختلف یک محصول نرم‌افزاری یا غیره را که چگونه است و چطور باید برنامه‌نویسی شوند به آن‌ها تسلط دارد. توسعه‌دهنده شخصی است که نباید فقط به یک زبان‌ یا ابزار برنامه‌نویسی اکتفا کند چرا که برای توسعه محصول حتما باید از چند زبان برنامه‌نویسی مورد نیاز در پروژه اطلاعات کاملی داشته و بتواند هر جا که نیاز بود کد‌ای مورد نیاز را توسعه و به نتیجه نهایی تبدیل کند. توجه داشته باشید که یک تیم شامل چندین توسعه دهنده به عنوان یک تیم کاملا حرفه‌ای و زبان زد محسوب می‌شوند برای مثال شرکت‌های بسیار بزرگ نه تنها برنامه‌نویسان حرفه‌ای در تیم خود استخدام می‌کنند بلکه توسعه دهندگانی را از نوع (Full-Stack) در اختیار دارند که مدیریت حساس پروژه را به عهده گرفته و پروژه را با دانشی که دارد به خوبی مدیریت می‌کند و زمانی که جایی پروژه به نکته‌ای برسد که برنامه‌نویسان توانایی حل آن را ندارند توسعه دهنده فول-استک می‌تواند با مهارت‌ها و تجربیات خود آن را حل کند. در رابطه با برنامه‌نویسان فول‌استک و ویژگی‌های این دسته از برنامه‌نویسان را در ادامه آورده شده است. 4.توسعه دهندگان فرانت-اند (UI/UX) این نوع توسعه‌دهندگان برنامه‌نویسانی هستند که مهارت کاملی در رابطه با لایه‌های مختلف و چندین زبان و فناوری‌های مورد نیاز در بخش User Interface و User Experience را دارند و می‌توانند طراحی مناسبی را متناسب با نوع پروژه و تجریبات مشتری ایجاد و توسعه دهند. این نوع برنامه‌نویسان یکی از مهمترین بخش‌های توسعه‌دهندگان در تیم محسوب می‌شوند که شاید تجربیات و بازخورد‌های مشتری را به سمت این نوع توسعه دهنده ارسال کنند. این نوع توسعه دهندگان علاوه بر داشتن دانش طراحی و تجربه کاربری دانش مرتبط با روانشناسی رنگ‌ها و جلوه‌های بصری دارند که آن‌ها را می‌توانند در قالب برنامه نویسی پیاده سازی کنند. 5.توسعه دهندگان بک-اند این نوع توسعه‌ دهندگان برنامه‌نویسان بسیار ماهری در بخش لایه‌های زیرین پروژه یعنی (منطقی) دارند که تمامی اطلاعات لازم را در رابطه با لایه‌های زیرین در اختیار دارند و می‌دانند چطور باید با دیتابیس ارتباط برقرار کنند، می‌دانند چطور باید با API‌های سیستم عامل کار کنند و می‌دانند کد‌های خود را بر اساس نوع ABI‌ و API‌ها چگونه باید مدیریت کنند؛ موارد بسیار زیادی که نیاز است در بخش منطقی یک پروژه ایجاد شود را به تنهایی حل و توسعه می‌دهند تا نتایج آن در اختیار توسعه دهنده فرانت اند قرار بگیرد. اما وظیفه‌ای در رابطه با طراحی تجربه‌کاربری و یا رابط کاربری نداشته و نمی‌توانند در این بخش مانور دهند. از این نوع توسعه دهندگان تنها می‌توان انتظار نوشتن کُدهای بی نقص و عالی در لایه‌های پایین را داشت. 6.توسعه دهندگان فول-استک این نوع توسعه‌‌دهندگان علاوه بر داشتن مهارت‌های مربو به برنامه‌نویسی، توسعه‌دهنده در فرانت‌اند و بک‌اند نیز هستند تجربیات و مهارت‌های بسیار زیادی در شاخه‌های دیگر علوم مهندسی کامپیوتری را دارند که نکته بسیار مهمی است! رسیدن به این درجه از برنامه‌نویسی یعنی یک مهندس کامل کامپیوتر که می‌تواند در تمامی بخش‌های یک پروژه در لایه‌های مختلف نرم‌افزار، سخت‌افزار، شبکه، پلتفرم‌ها و … صاحب نظر باشند و آن را توسعه دهند. یک فول استک به تنهایی می‌تواند رهبری یک پروژه را بر عهده بگیرد و درصورتی که نیاز باشد به تنهایی یک پروژه را از صفر تا صد تولید توسعه و اجرا نماید. این نوع توسعه‌دهنده‌ها یک مهندس واقعی کامپیوتر (نرم‌افزار) هستند که به خوبی می‌دانند یک محصول نهایی باید تحت چه شرایطی توسعه و اجرا شود. البته به این نکته توجه کنید توسعه‌دهنده‌های فول‌استک هم می‌توانند از لحاض محدودیت دسته‌بندی شوند، بعضی از آن‌ها صرفاً در یک حوزه تسلط کافی دارند، مانند Full Stack Web Developer یا Full Stack Android Developer به معنای این است که این گونه توسعه‌دهنده‌ها می‌توانند یک محصول را در سطح وب به طور کامل طراحی و پیاده سازی کند و یا در حوزهٔ ساخت و ساز اپلیکیشن‌های اندروید یک محصول را به طور کامل طراحی و برنامه‌نویسی کند. در غیر این صورت تنها واژهٔ Full Stack Developer می‌تواند پوشش کاملی بر تسلط کامل یک فرد با تخصص‌های بسیار بالا در ساخت و ساز یک محصول در پلتفرم‌های متنوع را بدهد که در یک پست جداگانه قبلاً به آن اشاره کرده‌ام: با توجه به تعاریف مرتبط با عناوین باید سعی کنیم که از اصطلاحات صحیح و عناوین مرتبط با خود استفاده کنیم چرا که در صورتی که شما یک برنامه‌نویس هستید نباید بگویید من یک توسعه‌دهندهٔ وب هستم! این کار باعث ایجاد انتظار از شما خواهد شد که به احتمال بسیار زیاد توانایی انجام آن را نخواهید داشت. حتی برعکس آن ممکن است شما یک توسعه‌دهنده باشید اما بگویید یک کُدر حرفه‌ای هستم! این واقعاً اشتباه است! در این صورت درجه تخصصی خود را به شدت تنزل داده‌اید. در فرصت مناسب‌تری در بارهٔ این موضوع، در قالب یک اینفوگرافیک اطلاعاتی نشر خواهم کرد.