https://virgool.io/feed/@MaryamMoghaddas fa 2026-06-17 02:03:52 https://files.virgool.io/upload/users/34147/avatar/N8mE58.jpeg?height=120&width=120 https://virgool.io/@MaryamMoghaddas https://virgool.io/Quera-Mag/front-end-developer-pro-skills-rqtuk21cr8er در بخش اول این پست، با مهارت‌های اساسی برای کار در دنیای فرانت‌اند (Front-End) آشنا شدیم. اگر تازه اول راه باشید، آشنایی با CSS ،HTML و جاوا اسکریپت کارتان را راه می‌اندازد. اما اگر می‌خواهید یک توسعه‌دهنده فرانت‌اند حرفه‌ای باشید، این مهارت‌ها به هیچ‌‌وجه کافی نیستند. در این پست می‌خواهیم سراغ مهارت‌های تکمیلی برویم که کیفیت کارتان را بالا می‌برند و متخصص خبره‌تری از شما می‌سازند. مهارت‌هایی مثل تست کد، کنترل نسخه، طراحی واکنش‌گرا، بهینه‌سازی دیزاین و آشنایی با ابزارهای جانبی.What is Front-end Development? by Masoud Garousianاگر در پایان این مطلب به یادگیری یک‌جای همه این تکنولوژی‌ها علاقمند شدید، سری به دوره «آموزش پروژه‌محور طراحی وب (Front-End) کوئرا کالج» بزنید. در این دوره صفر تا صد مفاهیم jQuery ،JavaScript Bootstrap ،CSS ،HTML و Ajax را با تمرین‌ها و پروژه‌های کاربردی می‌آموزید و فرصت این را دارید که برای استخدام در اسنپ‌فود و اسنپ به مصاحبه دعوت شوید.آزمونِ کد (Testing Code)چه وب‌سایتی برای فروش بافتنی‌های مادرتان بسازید و چه سایتی جهانی برای بانکداری آنلاین، باگ‌ها همیشه بخشی از فرایند برنامه‌نویسی هستند. اگر می‌خواهید کد تمیز، بدون باگ و راحت‌فهمی بنویسید که به سادگی بشود در وقت لزوم تغییرش داد، حتما باید کدتان را به طور مداوم و در طول مسیر تست کنید. نوشتن آزمونِ کد شاید زمان‌بر باشد، اما ارزش‌اش در بلندمدت معلوم می‌شود. چند سال که گذشت، با خودتان فکر می‌کنید که عجب کار خوبی کردم آن موقع کدم را تست کردم! تست‌هایی که می‌توانید بنویسید انواع مختلفی دارند؛ مثلا:آزمون واحد (Unit Test) که در آن ریزترین اجزای کدتان را مستقل و و جدا از بقیه کد می‌سنجید. در این نوع تست به وابستگی‌ها (Dependencies) توجهی نمی‌کنید و فقط آن ماژول خاص را مورد سنجش قرار می‌دهید.آزمون یکپارچه‌سازی (Integration Test) که در آن ماژول‌هایی که قبلاً از آزمونِ واحد با موفقیت خارج شده‌اند را می‌گیرید و عملکردشان را با هم و در کنار یکدیگر بررسی می‌کنید.آزمون عملکردی (Functional Test) که کارکرد یک بخش به‌خصوص از سایت‌تان را بررسی می‌کند تا مطمئن شوید که آن قسمت همان کاری را انجام می‌دهد که شما می‌خواهید.تست کد بخش مهمی از فرایند توسعه فرانت‌اند است؛ اما خوشبختانه، در اینجا هم فریم‌ورک‌های متنوعی هستند که به دادتان برسند. هیچ نیازی نیست که همه آن‌ها را یاد بگیرید؛ می‌توانید هرکدام را دوست داشتید انتخاب کنید و تست‌هایتان را با آن بنویسید.برخی از فریم‌ورک‌های تست کد در فرانت‌اند را با هم مرور کنیم: جست (Jest) که توسط فیسبوک ساخته شده، یکی از محبوب‌ترین فریم‌ورک‌های تستینگ است. با اپلیکیشن‌های ری‌اکت خیلی خوب کار می‌کند، اما در عین حال می‌توان آن را برای هر فریم‌ورک مدرنی در جاوا اسکریپت به کار برد.موکا (Mocha) فیچر‌های خیلی زیادی دارد، روی Node.js و در مرورگر اجرا می‌شود و تست ناهمگام را برایتان ساده و مفرح می‌کند.آنزیم (Enzyme) ابزاری برای تست کامپوننت در ری‌اکت است و بررسی (Assert)، دستکاری و پیمایش (Traverse) خروجی کامپوننت‌های ری‌اکت را برایتان آسان می‌کند. آنزیم آزمون واحد نیست، بلکه چرخه عمر کامپوننت را می‌سنجد. این سه فریم‌ورک از محبوب‌ترین‌‌ها برای تست کد جاوا اسکریپت هستند، اما گزینه‌های شما به همین‌جا ختم نمی‌شود. نظرسنجی وضعیت جاوا اسکریپت در سال ۲۰۱۹، لیستی از چندین فریم‌ورک محبوب دیگر برای آزمون کد دارد که می‌توانید میزان رضایت، علاقه و آگاهی برنامه‌نویسان از هرکدام را با هم مقایسه کنید و بعد تصمیم بگیرید که با کدام جلو بروید.کنترل نسخه (Version Control) و کار با گیت (Git)در طول همه آن نشانه‌گذاری‌ها با HTML، زیباسازی‌ها با CSS و برنامه‌نویسی‌ها با JavaScript، احتمالاً چندین و چند بار کدتان را بازبینی خواهید کرد. فرض کنیم زد و یک جای کار اشتباهی پیش آمد. در این مواقع وحشتناک‌ترین چیزی که می‌تواند پیش بیاید این است که مجبور شوید همه چیز را از اول شروع کنید! کنترلِ نسخه فرایندی برای تعقیب و کنترل تغییرات ایجاد شده در کدِ منبع شما است تا لازم نباشد به چنین داستان‌های ترسناکی فکر کنید!با نرم‌افزار کنترل نسخه می‌توانید به نسخه قبلی کارتان برگردید و بدون این‌که کل کار را بکوبید، ایراد نسخه جدیدتر را پیدا کنید. نرم‌افزار متن‌باز گیت، دوست همیشه پایدار برنامه‌نویس‌ها برای این کار است که خیال‌تان را راحت خواهد کرد. کار با کنترل نسخه، مهارتی است که هم شما و هم کارفرماهای آینده‌تان از داشتنش بسیار خوشحال خواهید شد.طراحی واکنش‌گرا (Responsive) و بهینه‌سازی دیزاینآن روزها را یادتان می‌آید که فقط از یک دستگاه برای سر زدن وبسایت‌ها استفاده می‌کردیم؟ نه، من هم یادم نمی‌آید. آن روزها که پی‌سی یا حتی لپ‌تاپ تنها راه سایت دیدن بود آن‌قدر تاریخ گذشته است که نمی‌خواهم با حرف زدن در موردشان سن خودم را بالا ببرم!این روزها ما وب‌سایت‌هایمان را با دستگاه‌های متنوعی از کامپیوترها، موبایل‌ها و تبلت‌ها چک می‌کنیم. تا حالا دقت کرده‌اید که چطور این صفحات خودشان طراحی‌شان را با توجه به دستگاه شما تنظیم می‌کنند؟ این به خاطر طراحی واکنش‌گرا است. به عنوان یک توسعه‌دهنده فرانت‌اند، آشنایی با اصول طراحی واکنش‌گرا و نحوه پیاده‌سازی‌ آن هنگام کدزنی، بخشی اساسی از کار شما است.اما کار یک وب‌سایت ایده‌آل همین‌جا تمام نمی‌شود. شما شاید بهترین و جذاب‌ترین وبسایت جهان را بسازید، اما اگر لود شدن آن هزار سال طول بکشد، تلاش شما کوچک‌ترین اهمیتی برای کاربر ندارد. برای بهبود سرعت وب‌سایت کارهای خیلی زیادی می‌توان انجام داد؛ مثلاً بهینه‌سازی عکس‌ها و تغییر اندازه آن‌ها، Lazy Load، حذف لودهای غیرضروری و بهینه‌سازی کدهای CSS ،HTML و جاوا اسکریپت.مقاله پیشنهادی از کوئرا مگ: راهکارهای مبتنی بر فرانت‌اند برای بهبود کارایی اپلیکیشنآشنایی با دیگر ابزارهای جانبیابزارهای Buildاین ابزارها برای خروجی‌گرفتن (Building) و دسته‌کردن (Bundling) کد کمک شایانی به شما می‌کنند. بهترین ابزارهای Build عبارت‌اند از وب‌پک (Webpack) و رول‌آپ (Rollup). وب‌پک یک ماژول Bundle ایستا برای اپلیکیشن‌های مدرن جاوا اسکریپت است. رول‌آپ هم قطعات کوچک کد را در یک قالب بزرگ‌تر و پیچیده‌تر مثل کتابخانه یا اپلیکیشن، کامپایل می‌کند. هم‌چنین رول‌آپ فرمت استاندارد جدید نسخه ES6 جاوا اسکریپت را برای ماژول‌های کد به کار می‌برد.ابزارهای خودکارسازیانجام‌دادن همه کارهای لازم برای بهینه‌سازی وب‌سایت می‌تواند خیلی وقت‌گیر باشد. اینجا است که ابزارهای اتوماسیون به کارتان می‌آیند. برنامه‌هایی مثل گرانت (Grunt) و گالپ (Gulp) به طور خودکار خیلی از این کارها را انجام می‌دهند. اگر می‌خواهید در سفر مدام‌تان به سوی کارایی بیشتر با صرف زمان کمتر به جایی برسید، آشنایی با این ابزارها به نفع‌تان خواهد بود.پکیج‌منیجرها (مدیریت بسته)پکیج‌منیجرها به درد نصب، به‌اشتراک‌گذاری و توزیع کد می‌خورند و وابستگی‌ها را هم در پروژه‌تان مدیریت می‌کنند. ان‌پی‌ام (NPM) یکی از رایج ترین پکیج‌منیجرها برای جاوا اسکریپت است. یارن (Yarn) هم پکیج‌منیجر محبوب من است که همه کارهای NPM را می‌تواند انجام دهد. به نظر می‌رسد این روزها خیلی‌ها دارند از ان‌پی‌ام به یارن مهاجرت می‌کنند، چرا که یارن هم سریع‌تر است و هم استفاده از آن راحت‌تر.لینترها و فرمترهاتا زمانی که پروژه‌تان هنوز کوچک است، IDE محبوبتان به خوبی خطاها و مشکلات کدتان را شناسایی می‌کند و به شما نشان می‌دهد. اما وقتی با یک تیم بزرگ کار می‌کنید که هر کس در آن ابزار خودش را استفاده می‌کند و پروژه هم زیادی بزرگ شده، دیگر استفاده از IDE برای خطایابی جوابگو نیست. در اینجا است که باید سراغ لینترها بروید. لینترها ابزار شناسایی خطاها هستند که اتفاقا IDEها با کمک آن‌ها خطاها را شناسایی می‌کنند.ای‌اِس‌لینت (ESLint)، پرکاربردترین لینتر مورد استفاده در دنیای فرانت‌اند است که فرمت‌بندی کار را هم مدیریت می‌کند. در ESLint می‌توانید قوانینی مبتنی بر معیارهای کدزنی فردی/تیمی مشخص کنید تا هرجا کدتان مطابق آنها نبود، ESLint شکارش کند. اگر از ای‌اِس‌لینت خوشتان نیامد و دنبال گزینه دیگری می‌گشتید، می‌توانید سراغ پرتی‌یر (Prettier) بروید.به یادگیری برنامه‌نویسی فرانت‌اند علاقمند شدید؟ برای ثبت نام در دوره فرانت‌اند کوئرا کالج کلیک کنید.ترجمه، اقتباس و تخلیص از:"5 Essential Skills Every Front End Developer Must Learn in 2019" by Adhithi Ravichandran @ Programmingwithmosh"The 10 Skills You Need to Land Your First Front End Developer Job" by Scott Morris @ Skillcrushکوئرامگ مجله‌ای تخصصی برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید توئیتر یا کانال تلگرام ما را دنبال کنید. مریم مقدس برهان مریم مقدس برهان Tue, 01 Sep 2020 18:07:28 +0430 https://virgool.io/Quera-Mag/front-end-developer-skills-ixs46xoeddhn دنیای توسعه وب، سرزمینی است که سه آرزوی بزرگ انسان‌ها در آن برآورده می‌شود: پول بیشتر، کار خلاقانه و برنامه کاری منعطف. اما از دور که به آن نگاه می‌کنیم، سرشار است از کلمات عجیب و غریب، زبان‌های بیگانه و کدهای ماورایی. با این‌حال اگر بدانیم که از کجا باید شروع کنیم، می‌بینیم که آنقدرها هم که فکر می‌کردیم سخت نبود. یک گزینه خوب برای ورود به بازار کار توسعه وب، آشنا شدن با توسعه فرانت‌اند (Front-End) است. توسعه‌دهندگان فرانت‌اند، طرح ذهنی شرکت‌ها از سایت‌شان را به واقعیت تبدیل می‌کنند. توسعه فرانت‌اند مسیر مستقیم و انعطاف‌پذیری برای ورود به دنیای برنامه‌نویسی است؛ چون فقط با کسب تعداد محدودی مهارت، می‌توانید نظر کارفرماها را به خود جذب کنید و فرصت شغلی مناسب خود را بیابید. به شما قول می‌دهم، توسعه‌دهندگان فرانت‌اند هیچ‌جا بیکار نمی‌مانند!برای موفق شدن در دنیای فرانت‌اند وب، چندین مهارت نیاز دارید که در این مطلبِ دو قسمتی قرار است شما را با آن‌ها آشنا کنم. در مطلب اول (دقیقا همین که در حال خواندنش هستید) مهارت‌های اساسی را مرور می‌کنیم؛ یعنی CSS ،HTML، جاوا اسکریپت و کتابخانه‌ها و فریم‌ورک‌های آن.اگر در پایان این مطلب به یادگیری یک‌جای همه این تکنولوژی‌ها علاقمند شدید، سری به دوره «آموزش پروژه‌محور طراحی وب (Front-End) کوئرا کالج» بزنید. در این دوره صفر تا صد مفاهیم jQuery ،JavaScript Bootstrap ،CSS ،HTML و Ajax را با تمرین‌ها و پروژه‌های کاربردی می‌آموزید و فرصت این را دارید که برای استخدام در اسنپ‌فود و اسنپ به مصاحبه دعوت شوید.مهارت اول: HTMLبرای قدم گذاشتن در وادی توسعه وب، اولین چیزی که باید یاد بگیرید HTML است. HTML یک زبان نشانه‌گذاری (Markup Language) استاندارد است که با آن صفحات وب را می‌سازند. زبان نشانه‌گذاری به زبانی گفته می‌شود که از تگ‌های به‌خصوص برای مشخص کردن بخش‌های مختلف متن استفاده می‌کند. وقتی به یک زبان نشانه‌گذاری می‌نویسیم، به خواننده نشان می‌دهیم که متن‌مان با یک نوشته معمولی در وُرد فرق دارد. HTML اولین ابزار در توشهٔ فرانت‌اندِ شما است و ساده‌ترین چیزی است که برای توسعه وبسایت نیاز دارید. در گذر سال‌ها، HTML حسابی رشد کرده و امروز جدیدترین نسخه آن HTML 5 است.مهارت دوم: CSSوقتی HTML را یاد گرفتید، متوجه می‌شوید صفحاتی که با آن طراحی کرده‌اید یک جورهایی... چطور بگویم، زشت هستند! چیزی که این صفحه‌ها لازم دارند، طرح و رنگ است و این یعنی CSS. با CSS می‌توانید صفحات‌تان را زیبا کنید و تجربه کاربری خوبی برای کاربران‌تان رقم بزنید.اضافه‌کردن رنگ، تعیین فونت‌ها، مشخص‌کردن سایز دکمه‌ها، گذاشتن تصویر پس‌زمینه، واکنش‌گرا کردن سایت برای دسکتاپ و موبایل و خیلی از زیبایی‌های دیگر صفحه وب، شاهکار دست CSS هستند. خیلی از توسعه‌دهندگان رابط کاربری، فقط با حرفه‌ای شدن در CSS و استفاده از همین یک مهارت، کلی پول درمی‌آورند.برای توسعه‌گر فرانت‌اند شدن، HTML و CSS هردو لازم و حیاتی‌اند. بدون این دو، امکان توسعه وب اصلا وجود ندارد! حتی یک فرصت شغلی برای توسعه فرانت‌اند هم نیست که این دو مهارت برای آن لازم نباشد.پیش‌پردازنده‌های CSSسی‌اس‌اس خیلی خوب است، اما محدودیت‌هایی دارد. مثلا یک مشکل آن این است که نمی‌شود در آن متغیرها و تابع‌ها را تعریف کرد یا جمع و تفریق انجام داد. این کمبودها زمانی روی اعصاب آدم راه می‌روند که پروژه بزرگ باشد و کدها مدام بیشتر و بیشتر شوند. آن وقت می‌بینید برای تغییر هر چیز جزئی‌ای باید ساعت‌ها خودتان را با نوشتن کدهای تکراری شکنجه کنید. مثلا اگر بخواهید رنگ آبی قسمت‌های مختلف سایت را تغییر بدهید، باید همه Hex Valueها (کدهای رنگی) را تک‌به‌تک پیدا و عوض کنید! پیش‌پردازنده‌های CSS آمده‌اند تا وقت و حوصله‌تان را از چنگال مشکلات CSS نجات بدهند و زندگی‌ را برای شما ساده‌تر ‌کنند.در پیش‌پردازنده‌ها، شما به زبان پیش‌پردازنده کد می‌زنید نه CSS. زبان پیش‌پردازنده به شما اجازه می‌دهد کارهایی که با CSS شکنجه بود را مثل آب خوردن انجام بدهید. مثلا برای عوض کردن رنگ آبی، فقط یکی از Hex Value‌ها را تغییر می‌دهید و بقیه خودبه‌خود عوض می‌شوند. بعد از این که کارتان تمام شد، پیش‌پردازنده کدها را به CSS تبدیل می‌کند و تحویل شما می‌دهد تا راحت روی وبسایت‌تان بگذارید و از نتیجه لذت ببرید!سَس (Sass)، لِس (Less)، پست‌سی‌اس‌اس (PostCSS) و استایلس (Stylus) همگی پیش‌پردازنده‌های محبوبی هستند. اما اگر من می‌خواستم فقط یکی از آن‌ها را انتخاب کنم، قطعا انتخابم Sass است(لیستی از آموزش‌های آنلاین سَس). اخیرا PostCSS هم خیلی دارد محبوب می‌شود. فکر خوبی است که بعد از یاد گرفتن Sass، سراغ آن هم بروید.مهارت سوم: جاوا اسکریپت (JavaScript)با کمک HTML و CSS، حالا توانسته‌اید وبسایت‌های زیبا و قشنگی طراحی کنید. اما این وبسایت‌ها صرفا یک سری زامبی‌های خوشگل هستند که شعور چندانی ندارند. می‌توانید از یک زامبی خوشگل بخواهید برای شما یک لیوان آب از یخچال بیاورد، اما اگر پارچ خالی باشد، آن زامبی عقلش نمی‌رسد که باید از شیرِ آب لیوان را پر کند. برای این‌که مغز وب‌سایتتان را کار بگذارید، به جاوا اسکریپت نیاز دارید.جاوا اسکریپت منطق و عملکردهای وبسایت را می‌سازد. Featureهای پیچیده‌ و تعاملی (Interactive) مثل صدا و ویدیو، بازی، امکانات اسکرول کردن و انیمیشن‌های صفحه همه حاصل جاوا اسکریپت است.با رشد CSS، امکان ساختن خیلی از این Feature‌ها هم دارد به آن اضافه می‌شود؛ با این حال هنوز راه زیادی مانده است. همانطور که نظرسنجی‌های سال ۲۰۱۸ و ۲۰۱۹ استک‌اورفلو نشان می‌دهد، جاوا اسکریپت فعلا محبوب‌ترین زبان برنامه‌نویسی است. این یعنی حالا حالا‌ها از دور خارج نمی‌شود و برای توسعه فرانت‌اند، باید آن را خوب و عمیق یاد بگیرید.مهارت چهارم: کتابخانه‌ها و فریم‌ورک‌های جاوا اسکریپتکوله‌تان را زمین بگذارید و نفس تازه کنید، شما بخش اعظم مسیر را آمده‌اید! حالا که سه مهارت اصلی برای توسعه فرانت‌اند (یعنی CSS ،HTML و جاوا اسکریپت) را یاد گرفته‌اید، وقتش است که کار کردن با آن‌ها را برای خودتان راحت‌تر کنید.کتابخانه‌ها و فریم‌ورک‌های جاوا اسکریپت (و همینطور CSS)، مجموعه‌ای از فایل‌ها به این زبان‌ها هستند که کارکردهای پراستفاده را در اختیار شما می‌گذارند. مثال بزنم؛ اگر خواستید کارکرد لاگین یا سرچ‌کردن را به سایت‌تان اضافه کنید، لازم نیست از اول برایشان کد بنویسید. خیلی راحت، می‌توانید فایلِ کدِ عملکرد را از کتابخانه بگیرید، آن هم با کدهای تمیز و مرتب! اجتماع بزرگی از توسعه‌دهندگان مدام دارند این فریم‌ورک‌ها را توسعه می‌دهند و همه به پیشرفت همدیگر کمک می‌کنند.اکثر اوقات انتخاب و مسلط‌شدن به یکی از فریم‌ورک‌ها کافی است و نیاز نیست از این شاخه به آن شاخه بپرید. سه فریم‌ورک برتری که خوب است به یاد گرفتن‌شان فکر کنید، این‌ها هستند: ری‌اکت (React)، انگولار (Angular) و ویو (Vue).۱. ری‌اکتمحبوب‌ترین کتابخانه جاوا اسکریپت در حال حاضر، ری‌اکت است که بیش از ۱۲۰ هزار ستاره در گیت‌هاب گرفته است. ری‌اکت را فیسبوک اوپن سورس کرده و امروزه اجتماع بزرگی از توسعه‌دهنده‌ها روی آن کار می‌کنند. این روزها بسیاری از اپلیکیشن‌های وب مدرن را با ری‌اکت می‌سازند.۲. انگولاراما اگر با ری‌اکت حال نمی‌کردید، چه؟ انگولار هم کتابخانه کاملی برای جاوا اسکریپت است که به اندازه ری‌اکت طرفدار دارد.اگر دوست داشتید این دو فریم‌ورک را با هم مقایسه کنید، با خواندن این پست می‌توانید تفاوت‌هایشان را بفهمید.۳. ویوفریم‌ورک Vue.js، تازه‌واردِ بازار است. ویو هم از انگولار الگو گرفته است و هم از ری‌اکت، اما خیلی سبک‌تر از آن‌ها است و به همین دلیل اخیرا طرفدارهای زیادی پیدا کرده است.اگر می‌خواهید ویو را با ری‌اکت مقایسه کنید، این پست گزینه خوبی است. مستندسازی رسمی Vue.js خیلی مرتب و منظم ساخته شده و بسیار به‌دردبخور است.تا اینجا را که یاد بگیرید، اصلی‌ترین بخش راه را آمده‌اید. اما اگر می‌خواهید سطح‌تان را از رقبایتان بالاتر ببرید، به مهارت‌های پیشرفته هم نیاز دارید‌! با ما باشید تا پست بعدی و آشنا شدن با کنترل نسخه، تست کد و ابزارهای مدرن توسعه وب!به یادگیری برنامه‌نویسی فرانت‌اند علاقمند شدید؟ برای ثبت نام در دوره فرانت‌اند کوئرا کالج کلیک کنید.ترجمه، اقتباس و تخلیص از:"5 Essential Skills Every Front End Developer Must Learn in 2019" by Adhithi Ravichandran @Programmingwithmosh"The 10 Skills You Need to Land Your First Front End Developer Job" by Scott Morris @ Skillcrushکوئرامگ مجله‌ای تخصصی برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید توئیتر یا کانال تلگرام ما را دنبال کنید. مریم مقدس برهان مریم مقدس برهان Wed, 26 Aug 2020 18:21:10 +0430 https://virgool.io/Quera-Mag/challenging-projects-every-programmer-should-try-fanaimcba3uu آستین هنلی، استاد دانشگاه تنسی -- کدام برنامه‌نویسی دوست ندارد یک پروژه جانبی برای خودش شروع کند؟ چه دانشجو باشید و چه باسابقه و مشغولِ کار، می‌دانید که پروژه‌های فرعی نه تنها رزومه آدم را چاق و چله می‌کنند، که یکی از بهترین راه‌ها برای یادگیری هستند. اما چیزی که خیلی‌ها نمی‌دانند، این است که دقیقا چه نوع پروژه‌ای؟این پست، مجموعه‌ای از ایده‌ها در جواب به این سوال است. من از تک‌تک این پروژه‌ها کلی چیز یاد گرفته‌ام؛ اما جذاب‌ترین ویژگی آن‌ها این است که آدم می‌تواند چندین بار آنها را بکوبد و دوباره از اول بسازد. در این بین، هربار هم چیزهای کاملا جدیدی را تجربه کند. هنوز هم که هنوز است، هر وقت می‌خواهم فریم‌ورک یا زبان برنامه‌نویسی جدیدی یاد بگیرم، سراغ یکی از این پروژه‌ها می‌روم.ادیتور متنما هر روزِ خدا از ادیتورهای متن استفاده می کنیم؛ اما تا حالا فکر کرده‌اید که اصلا ادیتورها چطور کار می‌کنند؟ یک دقیقه همه امکانات هیجان‌انگیز ادیتور محبوب‌تان را کنار بگذارید و ساده‌ترین حالت یک ادیتور را در نظر بگیرید؛ اصلا چطور می‌شود تکست‌باکسی ساخت که هم یک نشانگر متحرک متن را ساپورت کند و هم بشود در آن از وارد کردن تا انتخاب و پاک کردن متن را انجام داد؟ نه نه! کامپوننت تکست‌باکسی که در فریم‌ورک GUI محبوب‌تان هست اینجا جواب نمی‌دهد!بزرگ‌ترین معمای ساخت ادیتور متن این است: متن کاربر را چطور در حافظه نگه داریم؟ اولین چیزی که به ذهن من رسید این بود که از یک آرایه استفاده کنم. اما کافی بود کاربر متن جدیدش را هر جایی غیر از آخر متن قبلی اضافه می‌کرد؛ آن وقت بود که ادیتورم گریبان می‌درید و سر به بیابان می‌گذاشت. خوشبختانه، ساختار داده‌های خوبی هست که می‌شود با یاد گرفتن‌شان این مسئله را حل کرد.چالش بعدی، نحوه حرکت نشانگر در متن است. تا حالا دقت کرده‌اید که در ادیتورهای معمول این اتفاق چطور می‌افتد؟ فرض کنیم نشانگر من وسط سطر باشد. اگر فلش رو به بالا را روی کیبوردم بزنم، نشانگر کجا خواهد رفت؟ آیا در یک ستون حرکت می‌کند و در سطر بالایی، دقیقا در نقطه بالای جایی که در سطر پایینی بود می‌ایستد؟ اگر سطر بالایی کوتاه‌تر از سطر فعلی باشد این اتفاق نخواهد افتاد. حالا فرض کنیم نشانگرم در این سطر کوتاه باشد و من دوباره فلش رو به بالا را بزنم. کافی ‌است به سطری برسم که به اندازه کافی بلند باشد، آن وقت نشانگر دقیقا به همان ستونی می‌پرد که در اولین خط بود! به عبارت دیگر، انگار نشانگر برای خودش یک جور حافظه دارد که مشخصات مکان قبلی‌اش را آنجا نگه داشته و به محض این که بتواند، سعی می کند به آن برگردد. شما را نمی‌دانم، اما من فقط وقتی خواستم ادیتور بسازم تازه متوجه این جزئیات شدم.وقتی در یک ادیتور استاندارد فلش بالا را می‌زنیم چه اتفاقی می‌افتد؟بعد از اینکه موفق شدید یک ادیتور ساده بسازید، از شما دعوت می‌کنم دو تا امکان را هم به آن اضافه کنید: اول Undo/Redo و دوم Word Wrapping. من سر Undo/Redo ماجراهای هیجان‌انگیزی داشتم. می‌خواستم آن را در بهینه‌ترین شکل ممکن بسازم. برای این کار اول سعی کردم آرایه‌ای از حالت‌های قبلی نگه دارم، بعد سراغ الگوی ممنتو (Memento) رفتم و سرانجام بالاخره به ایجاد الگوی فرمان (Command Pattern) رضایت دادم.امکان Word Wrapping همان چیزی است که باعث می‌شود برای دیدن بقیه متن، نیازی به اسکرول کردن به چپ و راست نداشته باشید. با این امکان، متن در یک نقطه مشخص می‌شکند و به سطر بعد می‌رود. اضافه کردن Word Wrapping، شما را به چالش می‌کشد تا در هر سطر از متن، جنبه‌های بصری را از جنبه‌های مربوط به حافظه جدا کنید.یادگرفتنی‌ها:ساختار داده‌های ذخیره متن: آرایه‌ (array)، طناب، Gap Buffer و Piece Tableعملکرد نشانگر متن و نحوه پیاده‌سازی آنالگوهای طراحی Undo/Redo: ممنتو و فرمانقدرت انتزاع برای جدا کردن مسئله‌های بصری متن از مسائل مربوط به حافظهمنابعی برای مطالعه بیشتر:ادیتور متن: ساختارهای دادهطراحی و پیاده‌سازی ادیتور متن Win32ساختارهای داده و الگوریتم‌ها در جاوا (لینک کتاب در لیب‌جن)بازی‌های دو بعدیحتی ساده‌ترین بازی‌ها هم برای کار کردن، اول باید الگوهای طراحی و ساختار داده‌های خاصی داشته باشند. هدف این پروژه این است که بتوانید بدون درگیر شدن با چیزهایی مثل دیزاین و گرافیک، یک بازی درست و حسابی را از اول تا آخر بسازید. من پیشنهاد می‌کنم از یک کتابخانه گرافیکی دو بعدی استفاده کنید که فقط امکانات ضروری را داشته باشد (مثلا SDL ،SFML یا PyGame)؛ چون موتورهای بزرگ طراحی بازی بخش‌های هیجان‌انگیز کار را از جلوی چشم شما پنهان می‌کنند.در قدم اول، باید یاد بگیرید روی صفحه طرح بکشید. من هیچ ایده‌ای نداشتم چطور می‌شود این کار را کرد. برای این کار اول صفحه را پاک می‌کنید. بعد طرح لازم برای هر قسمت از صفحه را می‌کشید؛ به شکلی که با سرعت زیاد (مثلا در حد چند بار در ثانیه) پشت سر هم نمایش داده شوند. این‌طوری به بیننده القا می‌شود که اشیاء دارند روی صفحه حرکت می‌کنند.در قدم بعدی، قرار است کلی چیز در مورد لوپِ بازی یاد بگیرید. هر بازی در واقع چرخه‌ مداومی است از طرح کشیدن، گرفتن ورودی‌های کاربر و پردازش منطق بازی.سپس یاد می‌گیرید چطوری ورودی‌های کاربر را پردازش کنید. قبل از انجام این پروژه، من هیچ‌وقت به ظرافت‌های فشار دادن، نگه ‌داشتن و رها کردن کلیدهای کیبورد و موس دقت نکرده بودم؛ چه برسد به نحوه پردازش چیز پیچیده‌تری مثل دابل‌کلیک. حالا فرض کنیم پردازش را یاد گرفتیم، اصلا چند وقت یک بار باید وجود ورودی از کاربر را چک کنیم؟ اگر مرتبا در حال چک کردن باشیم، بازی‌ قرار است همیشه هنگ کند!چهارمین چیزی که یاد می‌گیرید، این است که همه شیءهای بازی‌تان را بسازید و مدیریت‌شان کنید. به عنوان مثال، چطور باید یک تعداد داینامیک از دشمن‌های بازی تولید کرد؟ الگوی Factory اینجا خیلی کمک می‌کند.در مرحله بعد، با منطق بازی و نحوه به کار بستن آن آشنا می‌شوید. موقعیت گلوله‌ها کِی آپدیت می‌شود؟ چه زمانی دشمن‌های بیشتری وارد صفحه می‌شوند؟ چطور می‌فهمید که دشمنی نابود شده است؟ بازی کِی تمام می‌شود؟ من قبل از بازی ساختن هرگز از عملگر پیمانه‌ای (Modulo Operator) استفاده نکرده بودم؛ اما حالا کد همه بازی‌هایی که ساختم پر از آن است.وقتی توانستید یک بازی اولیه را با موفقیت به کار بیندازید، می‌توانید کلی چیزهای دیگر هم به آن اضافه کنید. منوی صفحه اولیه بازی را بسازید، صفحه گیم‌اور اضافه کنید، چک کنید که سرعت بازی در کامپیوترهای مختلف یکی باشد و یاد بگیرید با کمک هوش مصنوعی، دشمن‌های پردردسرتری خلق کنید. از این هم بیشتر چالش می خواهید؟ شیدر افکت (Shader Effect) اضافه کنید، صدا به بازی بیاورید و حتی ورژن چند نفره آنلاین از بازی بسازید.یادگرفتنی‌ها:طرح کشیدن روی صفحهمدیریت ورودی‌های کاربرلوپ بازیساخت و مدیریت تعداد داینامیکی از شیءها در بازی (مثلا با فکتوری پترن)ماشین حالت برای دشمن‌های ساخته شده با هوش مصنوعیپخش صدااستفاده از شیدرشبکه‌سازی برای اضافه کردن امکانات آنلاینمنابعی برای مطالعه بیشتر:الگوهای نوشتن بازیساختارهای داده برای بازی‌نویس‌ها (لینک لیب‌جن)نوشتن بازی هوش مصنوعی همراه با مثال (لینک لیب‌جن)هشت درسی که از منتشر کردن هشت بازی ویدیویی یاد گرفتمکامپایلر - تاینی‌بیسیکساختن کامپایلر، آموزنده‌ترین پروژه‌ای است که به عمرم روی آن کار کرده‌ام. همین حالا هم اگر عصر جمعه‌ای وقت خالی برای کد زدن داشته باشم، به احتمال زیاد روی یک کامپایلر کار می‌کنم. حس خیلی قشنگی دارد که چیزی خلق کنی، بعد دیگران با کمک آفریده‌ تو بتوانند کلی چیز بیشتر خلق کنند. فقط با ساختن یک کامپایلر، کلی اطلاعات در مورد پیچیدگی‌های کامپایلرها یاد گرفتم که در حالت عادی حتی به آن‌ها فکر هم نکرده بودم.پیشنهاد می‌کنم سراغ یک زبان مختصر و بیسیک‌طور (مثلا Tiny Basic) بروید و کامپایلر را از اول تا آخر برای آن بسازید. بعد می‌توانید آن را برای هر زبان دیگری که خوب بلدید، کامپایل کنید. مثلا می‌توانید یک کامپایلر تاینی‌بیسیک در پایتون بنویسید که خروجی‌اش کد سی‌پلاس‌پلاس باشد. هیچ نیازی نیست که خروجی‌تان اسمبلی یا سی باشد. اصلا دوری کردن از این زبان‌ها باعث می‌شود حاشیه‌ها را ول کنید و خود کامپایلر را بچسبید.ساختن کامپایلر یکی از آموزنده‌ترین پروژه‌هایی است که می‌توانید روی آن کار کنید.اولین مانعی که با آن روبرو خواهید شد، این است که چطور کد ورودی را تحلیل واژه‌ای یا Tokenize کنید. بعد قرار است کدتان را تجزیه (Parse) کنید؛ یعنی ساختار ورودی‌ها را بررسی کنید و یک نمود درختی از کدتان بسازید. تکنیک تجزیه کاهشی بازگشتی برای این کار بی‌نظیر است. در قدم بعدی معنای ورودی‌ها را چک می‌کنید، مطمئن می‌شوید که کدتان معنا و مفهوم دارد و از قوانین تایپ (Type Rules) پیروی می‌کند. در آخر هم طبق معمول خروجی‌ می‌گیرید!برای این پروژه به‌خصوص، کلی منابع آموزشی از قبل وجود دارد که حسابی کمک‌تان می‌کند. نگذارید اصطلاحات ناآشنای این وادی تهِ دل‌تان را خالی کنند. فقط در عرض چند روز می توانید یک کامپایلر ساده را تمام کنید. به‌علاوه، بی‌نهایت امکان هست که می‌توانید به کامپایلرتان اضافه کنید. وقتی ورژن اولیه را راه انداختید، می‌توانید یک کتابخانه استاندارد هم برایش بیاورید (من در PeayBASIC فانکشن ساده گرافیک دوبعدی را اضافه کردم)، کامپایلر بهینه‌سازی اضافه کنید و پیام‌های خطا را بهبود دهید. یادتان نرود که حتما چند تا برنامه نمونه هم با کامپایلرتان بنویسید تا بتوانید پزش را به کل دنیا بدهید!یادگرفتنی‌ها:تحلیل واژه‌ای (Lexical Analysis)تحلیل نحوی (Syntactic Analysis)تجزیه‌کننده کاهشی‌بازگشتی (Recursive Descent Parsing)درخت نحوی انتزاعی (Abstract Syntax Tree)تحلیل معنایی (Semantic Analysis)کامپایلر بهینه‌سازی (Optimization Passes)تولید کد (Code Generation)منابعی برای مطالعه بیشتر:آموزش ساخت مفسرچطور در Go، مفسر بنویسیم (لینک لیب‌جن)بیایید با هم کامپایلر بسازیمسورس کد PeayBASIC (گیت‌هاب)مینی‌سیستم‌عاملدر گذر سال‌ها، من بارها دیده‌ام که چقدر مفاهیم بنیادی سیستم‌عامل‌ها را در حیطه‌های گوناگونی پیاده می‌کنم؛ از بازی‌ها گرفته تا مدل‌های پیش‌بینی‌کننده رفتار انسان. شاید سر کلاس درس، الگوریتم‌ها و ساختار داده‌های استفاده شده در سیستم‌عامل‌ها به نظرتان بی‌فایده و انتزاعی بیایند؛ اما واقعیت این است که بی‌اندازه به درد می‌خورند. پیاده‌‌ کردن یک سیستم‌عامل به من کمک کرد تا خیلی بهتر بفهمم که در زیربنای این ساختار عظیم و غول‌آسا واقعا چه می‌گذرد.در مقایسه با موارد قبلی، این پروژه کمی زمان و تلاش بیشتری برای یادگیری می‌خواهد. همچنین از آن‌جا که سخت‌افزار نقش مهمی در آن دارد، ممکن است برخی موانع هم در سر راه انجامش داشته باشید. اما اگر طبق دستورالعمل‌های یک راهنما یا کتاب جلو بروید، قطعا موفق می‌شوید یک سیستم‌عامل بوت‌شدنی بالا بیاورید که برنامه‌هایی که خودتان نوشته‌اید را اجرا کند. این کتاب رایگان نوشته همکار من و یکی از بهترین راهنماها برای این کار است.یادگرفتنی‌ها:کراس‌کامپایلربوت‌لودرهاوقفه‌های بایوس (BIOS interrupts)حالت‌های مختلف x86مدیریت حافظه و صفحه‌بندی (Paging)زمان‌بندی؛ مثلا الگوریتم راند رابین (Round Robin)فایل‌سیستم‌ها؛ مثلا FATمنابعی برای مطالعه بیشتر:ویکی منابع OSDev.orgساخت سیستم عامل RISC-V با زبان راست (Rust)مفاهیم سیستم‌عامل‌ (لینک لیب‌جن)فکر می‌کنید این پروژه‌ها بچه‌بازی است؟ این دوتای دیگر را امتحان کنید:اسپردشیت (Spreadsheet)نرم‌افزار اسپردشیتی مثل اکسل (Excel)، چالش‌های ادیتور متن را با چالش‌های کامپایلر ترکیب می‌کند. در جریان ساخت چنین نرم افزاری، یاد می‌گیرید که چطور محتوای هر خانه (Cell) را در حافظه نشان بدهید. همچنین متوجه می شوید که چطور باید مفسرها را برای زبان‌های مورد استفاده در معادلات پیاده‌سازی کنید.منابعی برای مطالعه بیشتر:گراف جهت‌دار غیرمدورپارادایم برنامه‌نویسی واکنش‌گرافناوری پیاده‌سازی اسپردشیت (لینک آمازون)شبیه‌ساز کنسول بازی ویدیوییشبیه‌ساز (Emulator) کنسول بازی، چالش‌های ساخت کامپایلر و سیستم‌عامل را یک جا دارد. نمی‌دانید چه حسی دارد که بتوانی بازی واقعی ساخت یک نفر دیگر را با شبیه‌ساز ساخت خودت بازی کنی!شبیه‌سازی یک کنسول واقعی، یعنی شما ماشین مجازی‌ای بنویسید که ادای CPU و دیگر بخش های سخت‌افزاری واقعی را دربیاورد. به این ترتیب می‌توانید بازی‌های ساخته شده برای آن کنسول را با شبیه‌ساز خودتان بازی کنید.من پیشنهاد می‌کنم قبل از رفتن سراغ یک کنسول بازی واقعی، اول CHIP-8 را شبیه‌سازی کنید. نینتندو، سوپر نینتندو، گیم‌بوی و گیم‌بوی ادونس همگی کاملا قابل شبیه‌سازی هستند، مستندسازی های فت و فراوان دارند و کلی شبیه‌ساز متن‌باز هم از قبل برای آن‌ها ساخته شده است. البته هرکدام از این کنسول‌ها نکته‌های خاص خودشان را دارند که کار را برای آدم جذاب می‌کند؛ مثلا ممکن است برای اجرا شدن بعضی بازی‌ها، لازم باشد باگ‌ها/فیچرهای مستندنشده یک سخت‌افزار به‌خصوص وجود داشته باشند. PICO-8 هم گزینه دیگری است که برای خودش کنسول «فانتزی» بسیار سوددهی شده است.منابعی برای مطالعه بیشتر:ساخت شبیه‌ساز CHIP-8شبیه‌ساز جاوا اسکریپت CHIP-8چطور گیم‌بوی را شبیه‌سازی کنیمسورس کد پای‌بوی (PyBoy) در گیت‌هاببعد از نوشتن این پست، من کلی پیشنهاد پروژه هم در هکرنیوز، ردیت، توییتر و از طریق ایمیل گرفتم که مرور آن‌ها خالی از لطف نیست:ساخت یک دیتابیس از بیخ و بنرهگیر نور (Ray Tracer)کلون برنامه Paint ویندوزادیتور گرافیکی وکتوردیکودر (Decoder) عکساپلیکیشن وب چت‌رومماشین‌حساب اعشار عدد پیابزارهای رایج ترمینال (مثلا grep)سرور و کلاینت FTPشما چه پروژه‌های هیجان‌انگیز دیگری سراغ دارید؟ ایده‌هایتان را در کامنت‌ها با ما در میان بگذارید.ترجمه‌ای از:"Challenging projects every programmer should try", by Austin Z. Henley کوئرامگ مجله‌ای تخصصی برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید توئیتر یا کانال تلگرام ما را دنبال کنید. مریم مقدس برهان مریم مقدس برهان Tue, 07 Jul 2020 19:22:15 +0430 https://virgool.io/Quera-Mag/writing-the-best-programming-resume-rkm9za9zbh9q ترنس کوئو، فری‌کدکمپ — راستش را بخواهید، من توسعه‌دهنده باتجربه‌ای نیستم. سابقه کار چندانی هم ندارم. حقیقتش را بگویم، وقتی این رزومه برنامه‌نویسی را نوشتم، دانشجوی سال آخری بیش نبودم. اما این رزومه کاری کرد که من از گوگل، فیس‌بوک، آمازون، مایکروسافت، اپل، و کلی جای دیگر مصاحبه بگیرم!من همان آدمی هستم که وقتی تازه دنبال کار بود، کیلو کیلو رزومه می‌فرستاد که مقصد هیچ‌کدام‌شان به جایی جز ریسایکل‌بین شرکت‌ها ختم نمی‌شد. چهار سالِ آزگار طول کشید تا بالاخره کشف کنم که چطور می‌توان کاری کرد که مسئول استخدام بی‌حوصله‌ای که ساعت پنج عصر در بین خرواری از رزومه‌ها گیر افتاده، ناگهان خواب از سرش بپرد!من راه درست را با چهار سال آزمون و خطای فراوان کشف کردم. اما شاید اگر یکی پیدا می‌شد و همان سال دوم دانشگاه یک رزومه درست و حسابی جلوی من می‌گذاشت، آن را برایم تشریح می‌کرد و نوشتنش را یادم می‌داد، دیگر اینقدر چشم انتظار یک تلفن و ایمیل از شرکت‌ها نمی‌ماندم. در این مطلب می‌خواهم نقش آن یک نفر را برای شما ایفا کنم. قرار است رزومه‌ای که از گوگل، فیس‌بوک، آمازون، مایکروسافت، و اپل برایم مصاحبه گرفت را خط به خط برایتان تحلیل کنم و اصولی که برای نوشتن رزومه یاد گرفته‌ام را با شما در میان بگذارم.چهار سال طول کشید تا من به این توصیه‌ها برسم، اما شما می‌توانید کل تجربه چهارساله مرا به همین سادگی، در حالی که روی تخت لم دادید و یک لیوان چای قندپهلو نوش جان می‌کنید یاد بگیرید! با این اصول می‌توانید فقط با درست نشان دادن خودتان و بدون گفتن هیچ دروغی، به شرکت‌ها نشان بدهید که می‌توانید نیروی خوبی برایشان باشید. امیدوارم اگر در جایگاه چهار سال پیش من هستید، این پست به شما کمک کند و بتوانید با آزمون و خطاهای خیلی کمتری به شغل دلخواهتان برسید.این شما و این رزومه‌ای که انبوهی از مصاحبه‌ها در شرکت‌های بزرگ تکنولوژی را برای من به ارمغان آورد: https://drive.google.com/open?id=1HqJvhX6TwwRT41aUIEXF-ivvS1ddNnpw این رزومه با کمک رزومه‌ساز آنلاین کوئرا بازنویسی شده است.شاید میلیون‌ها روش برای انجام یک کار وجود داشته باشد، اما اصول انجام آن کار از تعداد انگشت‌های دست بیشتر نیستند. کسی که اصول را بفهمد، می‌تواند با موفقیت روش خودش را انتخاب کند. کسی که روش‌ها را تست می‌کند و اصول را نادیده می‌گیرد، قرار است حسابی به مشکل بخورد. - رالف والدو امرسونضروریات در یک نگاهاول بیایید یک نگاه کلی به این رزومه بیندازیم:۱. خلاصه اما مفید مسئولان استخدام نمی‌توانند تا شب بنشینند و رزومه شما را بخوانند. به طور میانگین، هر رزومه کمتر از ۶ ثانیه توسط مسئولان استخدام بررسی می‌شود! پس رزومه‌تان را مختصر و مفید نگه دارید.۲. ثابت بودن دیزاین و فونت در همه بخش‌هامطمئن شوید که همه بخش‌ها ظاهر مشابهی دارند. تغییر ندادن دیزاین، خواندن رزومه را آسان‌تر می‌کند. هرچه خواناتر‌ بهتر!بخش‌های رزومهحالا بیایید تک‌تک قسمت‌های این رزومه را با هم بررسی کنیم:۱. من کی‌ام؟بیایید از ساده‌ترین بخش شروع کنیم؛ یعنی اسم‌تان. اسم‌تان را در بالای رزومه‌تان بنویسید، یک فونت راحت‌خوان برایش بگذارید، سایزش را بزرگ کنید، و رنگی برایش بگذارید که به راحتی قابل خواندن باشد.نیازی نیست رنگ‌های عجیب و غریب بگذارید یا دنبال فونت‌های خاص بگردید. یک فونت ساده و خوانا بهترین انتخابی است که می‌توانید داشته باشید. هدف شما این نیست که مسئول استخدام را با شوک ناشی از رنگ‌های جیغ فراری بدهید؛ بلکه صرفا قرار است کاری کنید که او بتواند در اولین نگاه و به راحتی اسم‌تان را بخواند. می‌خواهید کاملا یادش بماند که شما کی هستید. هرچقدر مسئول استخدام کمتر برای خواندن رزومه به زحمت بیفتد، آدم خوشحال‌تری خواهد بود. و یک آدم خوشحال بیشتر ممکن است که از شما برای مصاحبه دعوت کند!اگر از رزومه‌‌سازهای آنلاین استفاده کنید، نگرانی انتخاب رنگ و فونت را نخواهید داشت؛ کل کاری که باید بکنید این است که اطلاعاتتان را در فرم‌های مربوطه وارد کنید. رزومه‌ساز خودش به طور خودکار همه چیز را در یک قالب ساده و تمیز جا می‌دهد.خلاصه: کاری کنید که مسئول استخدام برای پیدا کردن و خواندن اسم شما حتی به یک ذره زحمت هم نیفتد!۲. اطلاعات تماسپیدا کردن اطلاعات تماس شما باید همانقدر راحت باشد که پیدا کردن اسمتان. این نکته خیلی مهم است! هر چیزی را هم که اشتباه کردید، این یک قلم را نباید اشتباه کنید! اگر شماره‌ یا ایمیلیتان را اشتباه بنویسید، طرف چطوری قرار است با شما تماس بگیرد؟ آن وقت روزها و ماه‌ها در انتظار جواب درخواست‌هایتان پیر می‌شوید و هزاران بار به لیاقت و مهارت خودتان شک می‌کنید، بدون این که بفهمید اصلا مشکل از یک جای دیگر بوده است.برای این که بیشتر خودتان را معرفی کنید، می‌توانید اکانت استک‌اورفلو، گیت‌هاب، بیت‌باکت و لینکدین‌تان را هم اضافه کنید؛ مثلا می‌توانید لوگوی هرکدام را بگذارید و آن را به صفحه مورد نظر لینک کنید تا رزومه‌تان زیادی شوغ نشود.خلاصه: اطلاعات تماستان را با دقت بنویسید، چون اگر اشتباه کنید هیچ‌کس قرار نیست با شما تماس بگیرد.۳. سابقه کاریقالب پیشنهادی رزومه برای برنامه‌نویس‌هاوقتی آدم دانشجو است و هیچ‌وقت در عمرش سر کار نرفته، با خودش فکر می‌کند که هیچ شرکتی قرار نیست حتی نیم‌نگاهی به رزومه‌اش بیندازد. نترسید، یادتان باشد که این رزومه‌ مال سال آخر من در دانشگاه است. من این فرصت را داشتم که در کارآموزی‌های تابستانی کمی تجربه کسب کنم، اما لازم نیست حتما چنین چیزی در چنته داشته باشید تا مصاحبه بگیرید. اگر به این نتیجه رسیدید که خیلی چیز مرتبطی برای گذاشتن در این قسمت ندارید، می‌توانید مستقیم بروید سراغ بخش «پروژه‌های شخصی» و آنجا جولان بدهید.اگر سابقه کار دارید، خوش به حال‌تان! اما یادتان باشد که هر سابقه کاری را نباید در رزومه گذاشت. اگر دنبال کار برنامه‌نویسی یا مهندسی نرم‌افزار می‌گردید، فقط شغل‌هایی را ذکر کنید که مهارت‌های لازم برای انجام آن‌ها، به مهارت‌های لازم برای این جایگاه شغلی ربط داشته باشند. متاسفانه، توانایی شما در صندوق‌داری یا سرو کردن غذا هیچ دلیلی بر این که مهندس نرم‌افزار خوبی خواهید شد، نیست.مسئولین استخدام دنبال کارجویانی می‌گردند که مجموعه مهارت‌های (Skill set) لازم برای آن شغل به‌خصوص را داشته باشند. هر چیز غیرمرتبطی که در رزومه ذکر شود، فقط باعث گمراهی است و وقت مسئول استخدام را بی‌خودی می‌گیرد. پس فقط تجارب کاری‌ای را ذکر کنید که به هر نوعی به جایگاه شغلی‌ای که دنبالش هستید ربط داشته باشند.خلاصه: فقط سوابق شغلی مهم و مرتبط را بنویسید. اگر سابقه شغلی ندارید، مهم نیست؛ بخش «پروژه‌های شخصی» نجات‌بخش شماست!۴. توضیحات شغل‌های پیشیننمونه سابقه‌های برنامه‌نویسی در رزومهاین بخش یکی از سخت‌ترین بخش‌های رزومه‌ است. صرف گفتن اسم و رسم شرکتی که آنجا کار کردید خیلی به درد کسی نمی‌خورد؛ اصل قضیه این است که بگویید آنجا چه کار کردید. از آن مهم‌تر، باید این کارها را طوری توضیح بدهید که خواننده بفهمد شما در آن شرکت آدم تاثیرگذاری بوده‌اید و نقش مهمی در پیشرفت شرکت داشته‌اید. باید نشان بدهید که نه تنها از پس شغلی که برایش اپلای کرده‌اید برمی‌آیید، که آن را خیلی هم خوب انجام می‌دهید. قرار است چیزی بنویسید که مسئول استخدام تا آن را خواند با خودش بگوید «این آدم همون چیزهایی رو بلده که ما می‌خوایم! این آدم تو پیشرفت شرکت قبلیش نقش داشته. این کسیه که ارزش مصاحبه و حتی همکاری رو داره!»من می‌خواستم موفقیت‌های گذشته‌ام – هرچند محدود – را به بهترین شکل ممکن در رزومه‌ام به نمایش بگذارم. برای این کار، از یک فرمول عالی استفاده کردم که لازلو باک (Laszlo Bock)، مدیر ارشد سابق منابع انسانی گوگل، ساخته است:«انجام کار x، به مقدار y، از طریق z.»من این فرمول را تا می‌توانستم در رزومه‌ام استفاده کردم. اگر نگاه کنید، می‌بینید که عملا همه توضیحات شغل‌ها و پروژه‌های من یک مدلی از همین فرمول هستند. (مشخصه که زیادی عاشق این فرمولم؟)مثلا این یکی را ببینید:بهبود هشت درصدی عمر باتری دستگاه، با اضافه کردن سنسور سوخت‌سنج و ایجاد وضعیت ذخیره باتریانجام x – ترکیب سنسور سوخت‌سنج و ایجاد وضعیت حفظ باتریبه مقدار y – 8%از طریق z – بهبود عمر باتری دستگاهآن بخش x را به هزار و یک روش می‌شود بیان کرد. مثلا من یک بانک واژگان برایتان جمع کردم که کلمات خیلی بدردبخوری برای توصیف این قسمت دارد:کلمات پیشنهادی برای استفاده در توضیحات سوابق کاراین هم یک سری نمونه‌جمله که می‌توانید با پرکردن جاهای خالی‌شان، جملات مناسبی برای رزومه خودتان بسازید:کاهش ___ درصدی ____ از طریق ______طراحی مجدد _____ به منظور _______پیاده سازی ______ به اندازه _____ با هدف ______بهبود ____ درصدی _____ با یکی کردن ______استفاده از _____ برای ساختن _____ و رسیدن به ________ایجاد ________ با اضافه کردن ______خلاصه: از فرمول «انجام کار x، به مقدار y از طریق z» برای نشان دادن موفقیت‌هایتان در شغل‌های قبلی استفاده کنید. این موثرترین و واضح ترین راه برای نشان دادن میزان اثرگذار بودن خودتان به مسئولین استخدام و مدیران است.۵. تکنولوژی‌هاتکنولوژی‌های برنامه‌نویسی در رزومهمن بعد از این که توضیحات هرکدام از سوابق کاری‌ام را دادم، زیرش می‌نویسم که از چه تکنولوژی‌هایی در آن کار استفاده کرده‌ام. اینطوری خواننده می‌تواند با یک نگاه بفهمد چه چیزهایی بلدم، و اگر حوصله خواندن توضیحاتم برای سوابق کار را نداشت، با همین تکنولوژی‌ها هم می‌تواند برداشتی کلی از توانایی‌هایم به دست بیاورد. من همین تکنیک را برای بخش پروژه‌ها هم پیاده کرده‌ام.وقتی لیست مفصل‌تر تکنولوژی‌ها را کنار سوابق کار و پروژه‌های مرتبط به آنها می‌آورم، رزومه‌ام یک مزیت دیگر هم پیدا می‌کند: می‌توانم بخش «مهارت‌ها» در آخر صفحه را هم مختصر و مفیدتر بکنم و فقط لیست زبان‌های برنامه‌نویسی را آنجا بیاورم. به این ترتیب اگر مسئول استخدام دنبال زبان خاصی باشد، خیلی راحت می‌تواند بفهمد که من چیزی از آن می‌دانم یا نه.خلاصه: اسم تکنولوژی‌هایی که با آنها کار کرده‌اید را در کنار سوابق کاری و پروژه‌هایتان بیاورید. اینطوری کار مسئول استخدام را برای شناخت تجربه و دانش‌تان ساده‌تر می‌کنید.۶. پروژه‌های شخصیپروژه‌های گیت‌هاب در رزومهاگر دنبال کار مهندسی کامپیوتر هستید، این بخش را قطعا، باید، حتما در رزومه‌تان داشته باشید! حاضرم پلاکارد دستم بگیرم و این را در کوچه و خیابان فریاد کنم: پروژه‌های فردی‌ مهم‌ترین بخش رزومه شما هستند، بخصوص اگر هیچ سابقه کاری‌ای نداشته باشید!اصلا مهم نیست چه چیزی ساخته باشید؛ چیزی که پروژه‌های شخصی به مسئول استخدام می‌گویند این است: «این آدم واقعا برنامه‌نویسی را دوست دارد. این آدم آنقدر برنامه‌نویسی را دوست دارد که حاضر بوده از تکالیف اجباری دانشگاه فراتر برود و فقط محض دل خودش کد بزند.»کی دوست ندارد در موردش اینطوری فکر کنند؟ این که آدم بدون هیچ‌گونه اجبار بیرونی برود و فقط چون یک پروژه‌ای را دوست دارد روی آن کار کند، واقعا قابل تحسین است. این کار نشان می‌دهد که شما از صمیم قلب دوست دارید در برنامه‌نویسی پیشرفت کنید، بیشتر یاد بگیرید، و از این که بیشتر از دیگران روی این کار انرژی بگذارید، نمی‌ترسید. در ثانی، با آوردن این پروژه‌ها در رزومه‌تان عملا دارید ابتکار عمل و ایده‌های خودتان را هم به مسئولین استخدام نشان می‌دهید.اگر تا به حال چیزی را محض دل خودتان نساخته‌اید، همین حالا شروع کنید. پروژه شخصی می‌تواند هرچیزی باشد: اسکریپت پایتون، برنامه جاوا، صفحه وبسایت، اپلیکیشن موبایل و هزار جور چیز دیگر. فایده آنها فقط برای رزومه نیست؛ بلکه با انجام دادن آن‌ها مهارت‌هایی به دست می‌آورید که در مشاغل دنیای واقعی هم به دردتان می‌خورند. در این پروژه‌ها آدم با چیزهایی کار می‌کند که در دانشگاه خیلی با آنها روبرو نشده، اما در محیط کار مرتبا از آنها استفاده خواهد کرد: مثل فریم‌ورک‌ها/کتابخانه‌های استاندارد، یادگرفتن توسعه وب فول‌استک، ساخت اپلیکیشن موبایل، درست کردن یک محیط توسعه، یا برنامه‌نویسی بهینه با ویم (Vim).اپ آیفون بسازید، اپ وب بسازید، اصلا هر اپی! واقعا مهم نیست چه چیزی می‌سازید؛ فقط باید یک چیزی بسازید. آدم می‌تواند فقط در دو روز آخر هفته یک پروژه جون‌دار و اساسی را تمام کند. این یعنی فقط با سه یا چهار تا آخر هفته کار کردن روی پروژه‌های شخصی، می‌توانید رزومه‌تان را از حالت «اِی، بدی نیست» به حالت «عالیه!» برسانید. جدی می‌گویم، خیلی‌ها را دیده‌ام که دقیقا همین کار را انجام داده‌اند.- گایل مک‌داول، از مهندسین سابق گوگل و نویسنده کتاب «شکستن قفل مصاحبه‌های برنامه‌نویسی»اگر شرکت بخصوصی هست که واقعا دلتان می‌خواهد آن‌جا کار کنید، یکی از بهترین راه‌ها برای متمایز کردن خودتان در انبوه رزومه‌ها این است: یک پروژه شخصی‌ انجام بدهید که مستقیما به کاری که می‌خواهید برایش اپلای کنید ربط داشته باشد.من کارآموزی‌ام در اتودسک (Autodesk) را با گذراندن یک دوره تعاملی رایگان در یودسیتی (Udacity) بدست آوردم. این دوره در مورد گرافیک کامپیوتری تعاملی (Interactive Computer Graphics) بود، و به من یاد داد که چطور از کتابخانه three.js جاوا اسکریپت استفاده کنم. به طور کاملا اتفاقی، اتودسک هم همان موقع دنبال یک کارآموز مهندسی نرم‌افزار بود که فول‌استک وبسایت و three.js بلد باشد؛ یعنی من!اما یادتان باشد: این استراتژی بی‌عیب و نقص نیست. این کار فقط برای شرکت‌هایی مثل اتودسک جواب می‌دهد که دنبال یک چیز مشخص هستند؛ نه شرکت‌هایی چون گوگل، فیس‌بوک، و مایکروسافت که کارآموزی‌هایشان برای «مهندسی نرم‌افزار به طور عام» است. اگر تازه دارید وارد بازار کار مهندسی نرم‌افزار می‌شوید، بهتر است اول به همین شکل عام و کلی کار کنید و یواش یواش با شاخه‌های تخصصی‌تر علوم کامپیوتر آشنا شوید. اما بهرحال اگر شرکت به‌خصوصی هست که واقعا دنبال کار در آنجا هستید، این روش ارزش امتحان کردن را دارد.یک توصیه دیگر: یک وبسایت شخصی بسازید که همه پروژه‌های شخصی‌تان را به دنیا نمایش دهد. با همین کار کوچک، می‌توانید اطلاعاتی خیلی بیشتر از یک صفحه را در رزومه یک صفحه‌ای‌تان جا بدهید.خلاصه: پروژه‌های شخصی حیاتی‌اند. اگر هنوز هیچ پروژه‌ شخصی‌ای در چنته ندارید، همین حالا یکی را شروع کنید! هیچ چیز از دست نمی‌دهید، اما کلی چیز به دست خواهید آورد.۷. تحصیلاترشته و دانشگاهی که در آن درس خوانده‌اید را هم در رزومه بنویسید!دانشگاه رفتن موفقیت بزرگی است؛ بخصوص اگر در دانشگاه‌های تاپ درس خوانده باشید. پس از جا دادن آن در رزومه‌تان نترسید. وقتی این قسمت را در رزومه‌تان می‌گذارید، در واقع دارید به مسئول استخدام می‌گویید که به یادگیری و تحصیل علاقه دارید؛ حتی اگر از رشته‌ای کاملا بی‌ارتباط به علوم کامپیوتر آمده باشید. این پوئن خیلی مثبتی است، چون تکنولوژی مدام در حال تغییر است و اگر کسی حال و حوصله یادگیری نداشته باشد، پیشرفتی هم در کارش نخواهد داشت. در ضمن، آن همه سال بیدار شدن از ۸ صبح و دوره‌ کردن‌های شب امتحانی تا ۵ صبح بالاخره باید به یک دردی بخورد! پس به دانشگاه رفتن‌تان افتخار کنید و آن را در رزومه‌تان بگذارید.حتما واحدهای درسی مرتبط به جایگاه شغلی مد نظرتان را هم بنویسید. قرار نیست یک عالمه اطلاعات به خوردِ مسئول استخدام بدهیم، بلکه هدف این است که تصمیم‌گیری را در مورد مناسب بودن‌مان برای جایگاه شغلی برایش راحت‌تر کنیم. همانطور که گفتم، مسئولی که زحمتش کمتر باشد، بیشتر ممکن است که از شما برای مصاحبه دعوت کند.خلاصه: بنویسید کجا تحصیل کرده‌اید. اگر درس مرتبطی پاس کرده اید، به آن هم اشاره کنید.۸. مهارت‌هاخود عنوان گویای همه چیز است. این بخش رزومه‌تان را مختصر و مفید و ساده بسازید. زیادی ریز و تخصصی نشوید. در این قسمت می‌توانید همه مهارت‌های مرتبطی که می‌خواهید مسئول استخدام از آن‌ها آگاه باشد را بنویسید. این مهارت‌ها هم می‌توانند شامل مهارت‌های نرم باشند (مثل توانایی کار گروهی) و هم مهارت‌های تخصصی.برای مهارت‌های تخصصی، یک تکنیک این است که سراغ آگهی شغلی شرکت مورد نظر بروید و توضیحاتش را چک کنید. کلمات تخصصی‌ای که در این توضیحات به کار رفته، بهترین راهنمای شما برای نوشتن مهارت‌هایتان هستند. ببینید چه چیزهایی از آن لیست را بلدید و آن کلمات تخصصی را در لیست مهارت‌ها بیاورید. وقتی مسئول استخدام ببیند که شما با شغلی که دنبالش هستند مطابقت دارید، بیشتر علاقه‌مند خواهد بود که شما را به مصاحبه دعوت کند.فقط حواستان باشد، قرار نیست هر کلمه‌ای که در آگهی شغلی آمده را اینجا لیست کنید! یادتان باشد که ما نمی‌خواهیم در رزومه دروغ بگوییم. شاید با این کار مصاحبه را بگیرید، اما اگر آنجا از شما در مورد این مهارت‌هایی که ادعا کرده‌اید دارید بپرسند، حسابی گیر خواهید افتاد. بعد از این که به مصاحبه دعوت شدید، می‌توانید راهنمای کوئرا برای مصاحبه فنی موفق را بخوانید تا از پسِ این مرحله هم به خوبی بر بیایید.فراموش نکنید که هیچ برنامه‌نویسی همه زبان‌ها و تکنولوژی‌هایی که یاد گرفته را هر روز تمرین نمی‌کند؛ بنابراین می‌توانید اطلاعاتی در مورد میزان مهارت‌تان هم اضافه کنید تا نشان بدهید که با چه زبان‌هایی آشنایی دارید، و در کدام‌ها مسلط و وارد هستید. این میزان را می‌شود در قالب درصد یا کلمات مبتدی-متوسط-پیشرفته نشان داد. یک راه دیگر هم این است که بگویید چند سال است دارید با آن زبان کد می‌زنید.خلاصه: وقتی دنبال شغل بخصوصی می‌گردید، توضیحات آگهی شغلی را بخوانید و از کلمات تخصصی مهم ذکر شده در آن در رزومه‌تان استفاده کنید تا شانس‌تان برای گرفتن مصاحبه بیشتر شود.نکات پایانیوقتی رزومه‌تان را می‌نویسید، یادتان نرود که خودتان باشید. رزومه شما، لیستی از موفقیت‌ها، توانایی‌ها، و علایق شخص شما است، نه آن چیزی که فکر می‌کنید مسئول استخدام می‌خواهد باشید. کل هدف رزومه این است که حقیقت خودتان را به آراسته‌ترین شکل ممکن نشان بدهید. فقط با یاد گرفتن همین کار، یعنی نشان دادن جذابیت‌های شخصیت واقعی‌تان، ارزش رزومه‌تان چند برابر خواهد شد. حالا اگر دریافت این اطلاعات در مورد خودتان را برای مخاطب (مسئول استخدام) آسان کنید، آن وقت دیگر نورِ علی نور می‌شود. طراحی شیک و ساده صفحه، مختصر و مفید نوشتن، و ارائه کردن اطلاعات به شکل کلمه کلیدی همه و همه برای این هستند که خواننده راحت‌تر رزومه‌تان را بخواند.آیا شما هم تکنیک و توصیه‌ای برای بهتر کردن رزومه سراغ دارید؟ ایده‌هایتان را در کامنت‌ها مطرح کنید!? اغلب توصیه‌های این مطلب به طور خودکار در رزومه‌ساز کوئرا رعایت می‌شوند! با عضویت در کوئرا و تکمیل کردن پروفایل‌تان، رزومه ایده‌آل‌تان را بسازید و برای ده‌ها شغل مهندسی نرم‌افزار در فرصت‌های شغلی کوئرا اپلای کنید!ترجمه و تلخیص از: "How to write a killer Software Engineering résumé", by Terrence Kuo @ FreeCodeCampکوئرامگ مجله‌ای تخصصی برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید توئیتر یا کانال تلگرام ما را دنبال کنید. مریم مقدس برهان مریم مقدس برهان Sat, 26 Oct 2019 21:44:36 +0330 https://virgool.io/Quera-Mag/%D8%AF%DB%8C%D9%BE%D9%81%DB%8C%DA%A9-%D9%85%D8%A7-%D8%B1%D8%A7-%D8%A8%D9%87-%DA%A9%D8%AC%D8%A7-%D8%AE%D9%88%D8%A7%D9%87%D8%AF-%D8%A8%D8%B1%D8%AF-%D8%AE%D9%88%D8%A8-%D8%A8%D8%AF-%D9%88-%D8%B2%D8%B4%D8%AA-%D8%AF%DB%8C%D9%BE%D9%81%DB%8C%DA%A9%D9%87%D8%A7-e1t3c5rnymqv در یکی از صحنه‌های فیلم «اگه میتونی منو بگیر» ساخته استیون اسپیلبرگ، یک مامور FBI به نام کارل هنرتی در جستجوی کلاهبرداری به نام فرنک ابگنیل جونیور وارد اتاق او در هتل می‌شود. ابگنیل در همان حالتی که لوله تفنگ به سمت صورتش گرفته شده، وانمود می‌کند که مامور مخفی پلیس است و خودش هم دارد دنبال ابگنیل کلاهبردار می‌گردد. سرانجام ابگنیل موفق می‌شود سر هنرتی را شیره بمالد و درست جلوی چشمان حیرت زده او از چنگش دربرود. این فیلم که شخصیت اصلی‌اش مدام بین واقعیت و دروغ در تلاطم است، قصه بچه نابغه‌ای است که مسیر بدی را در پیش گرفته است. این روزها همین قصه را داریم در رسانه‌ها از نو زندگی می‌کنیم: همه‌ما هنرتی‌هایی هستیم که توانایی‌مان برای تشخیص راست از دروغ، حقیقت از کلک، و درست‌کاری از بدبینی به بازی گرفته شده است. کلاهبردار این قصه اگر گفتید کیست؟ بله، دیپ‌فیک‌ها.فرنک ابگنیل جونیور (لئوناردو دیکاپریو) در حال جا زدن خود به عنوان یک مامور مخفی در «اگه میتونی منو بگیر»دیپ‌فیک از کجا می‌آید؟کلمه دیپ‌فیک‌ (Deepfake) ترکیبی است از Deep Learning و Fake. شاید قبلا سایت «این فرد وجود خارجی ندارد» را دیده باشید؛ این سایت با کمک هوش مصنوعی، عکس پروفایل‌های آدم‌‌هایی را می‌سازد که هرگز وجود نداشته‌اند. چطوری؟ با الگوریتم شبکه مولد تخاصمی (Generative Adversarial Network) یا به طور خلاصه، گَن (GAN). این الگوریتم خودش برای خودش یک پا «اگه می‌تونی منو بگیر» است و ابگنیل و هنرتی انحصاری خودش را دارد:نحوه کارکرد شبکه مولد تخاصمی (گَن) به زبان «اگه می‌تونی منو بگیر»گَن یک بخش «مولد» دارد و یک بخش «ممیز». مثلا فرض کنید گَن قصه ما، یاد گرفته باشد تصویرهای دروغین از خلبان‌ها بسازد. مولد یا همان ابگنیل قصه، دارد سعی می‌کند عکس‌های تقلبی جعل کند. از آن طرف ممیز یا هنرتی داستان، عکس‌های جعلی ساخت مولد و عکس‌های واقعی را کنار هم می‌گذارد و به خودش یاد می‌دهد که عکس واقعی را از دروغی تشخیص دهد. هرچقدر که مدل گَن بیشتر یاد بگیرد، هر دو بخش‌های مولد و ممیز هم در کارشان بهتر عمل می‌کنند و هرکدام باعث می‌شود دیگری در کار خودش ماهرتر شود. دیپ‌فیک‌ها جعل‌هایی هستند که مولد بلاخره توانسته از زیر دماغ ممیز رد کند!بد: جعل، تحقیر، و دروغپیشرفت فناوری دیپ‌فیک حالا به جاهای نگران‌کننده‌ای رسیده است. نه فقط عکس‌های تقلبی، که حالا می‌شود با این فناوری ویدیوهای فیک هم ساخت. خوشبختانه ویدیوهای دیپ‌فیک هنوز در ابتدای مسیرند و هرکس بخواهد آنها را بسازد، باید فریم به فریم ادیتشان کند. علاوه بر این، بیشتر می‌شود تغییرات ظاهری ایجاد کرد نه حرکات واقعی. اما با همه اینها، همین دو سال پیش کاربر ناشناسی در ردیت با نام مستعار deepfakes، چهره گَل گَدو، بازیگر نقش واندر وومن را روی یک ویدیوی مستهجن گذاشت. کاربری دیگر در ردیت، اپی به نام فیک‌اپ ساخت که با آن می‌شد به سادگی ویدیوهای فیک ساخت و به اشتراک گذاشت. امروز دیگر جایگزین کردن چهره یک نفر در ویدیو با یکی دیگر نه تنها کار سختی نیست، که نتیجه آن هم تا حد خیلی خوبی غیر قابل تشخیص است. https://www.aparat.com/v/x1SDi فیلمسازی به نام جردن‌ پیل (Jordan Peele) دیپ‌فیکی ساخته که در آن باراک اوباما دارد در مورد خطرات دیپ‌فیک هشدار می‌دهد.در دنیایی که روزانه ۹۳ میلیون سلفی در آن گرفته می‌شود، تصور کردن انواع سوءاستفاده‌ها و جرایمی که می‌شود با دیپ‌فیک انجام داد، خیلی کار سختی نیست: ساخت ویدیوهای مستهجن برای انتقام‌گیری، باج‌گیری، سرقت هویت، پخش اخبار دروغ. تازه، اینها تنها چند مثال از انبوه گزینه‌های ممکن است. در قالب تئوری، تک‌تک افرادی که عکس خودشان را در شبکه‌های اجتماعی به اشتراک بگذارند در آینده در مقابل چنین حملاتی آسیب‌پذیر خواهد بود. ویدیوهایی مثل این سخنرانی فیک اوباما را با این فناوری می‌شود در انواع و اقسام تولید کرد، افرادی که مستعد گول خوردن هستند را با آنها به راحتی گول زد، و بعد اعضای جامعه دو قطبی امروز حتی بیشتر از قبل با هم دشمن می‌شوند. وقتی اینترنت و شبکه‌های اجتماعی بی‌سانسور و کنترل نشده ما سرشار از دیپ‌فیک شوند، کل جامعه و زندگی‌های خصوصی تک‌تک ما در خطر خواهد بود.زشت: گرداب بی‌پایان رقابت‌هامثل هر نوع یادگیری ماشینی و غیر ماشینی دیگر، برای ساختن دیپ‌فیک‌های واقع‌گرایانه هم اول باید داده کافی جمع کرد. اما این خیلی هم کار ساده‌ای نیست. کوین روز (Kevin Roose)، یکی از نویسندگان ستون فناوری در نیویورک تایمز، تصمیم گرفت با دادن یک سری ویدیو از خودش به اپلیکیشن فیک‌اپ، خودش امتحان کند. دیپ‌فیکی که او با این روش از خودش ساخت بامزه بود، اما آنقدر واقعی نبود که آدم را گول بزند. بنابراین به نظر می‌رسد که فعلا، فقط از اشخاص مشهور می‌شود دیپ‌فیک «واقعی» ساخت؛ یعنی آنهایی که کلی ویدیوی باکیفیت ازشان در سطح وب وجود دارد. اما همین هم چیز کمی نیست؛ مثلا دیپ‌فیک‌ سیاستمداران می‌تواند بین صدها میلیون آدم دست به دست بچرخد و نتایج زیانباری برای وقایع سیاسی مهم داشته باشد؛ مثلا برای نتایج انتخابات ریاست جمهوری آمریکا در سال 2020.احتمال بروز چنین اتفاقاتی، بار سنگینی بر دوش فناوری‌های تشخیص و شکار دیپ‌فیک گذاشته است. متخصصان مختلف دارند همه تلاششان را می‌کنند تا ابزارهای قدرتمندی برای تشخیص دیپ‌فیک بسازند. مثلا پژوهشگران دانشگاه واشنگتن، سایت «کدام چهره واقعی است» را ساخته‌اند که در آن می‌توانید بعد از خواندن مطلبی در مورد نحوه تشخیص تصاویر دیپ‌فیک، سعی کنید بین یک سری عکس‌های واقعی و جعلی، واقعی‌ها را تشخیص دهید. کایل مک‌دانلد هم در یک پست وبلاگ در مورد همین مسئله توضیح داده است. گروهی از محققان یک دیتاست عظیم ویدیویی جمع کرده‌اند که قرار است در علوم قانونی (Forensics) برای تشخیص جعل عکس، نقش محک و معیار را داشته باشد. استارتاپ دیپ‌تریس (Deeptrace)، مبارزه با خطرات سایبری دیپ‌فیک را به عنوان هدف خود برگزیده و گزارشی در مورد وضعیت دیپ‌فیک در سال 2018 ارائه کرده است. هنری فرید در دارت‌ماوت دارد نرم‌افزاری برای شناسایی دیپ‌فیک‌های ویدیویی سیاسی می‌سازد. سیوی لیو با همکاری آژانس پروژه‌های پژوهشی پیشرفته دفاعی (دارپا)، در حال توسعه نرم‌افزاری است که بتواند دیپ‌فیک‌های ویدیویی را شناسایی کرده و از انتشار و رواج آنها جلوگیری کند.همه اینها عالی است، اما مسئله اینجاست: دیپ‌فیک‌ها درست مثل ویروس‌های کامپیوتری هستند. به محض اینکه یکی راه شناسایی‌ ویروسی را پیدا کند، فوری یک نفر دیگر می‌آید و راهی برای دور زدن راهکار نفر قبلی پیدا می‌کند. این قایم‌موشک‌بازی بین جعل‌کننده‌ها و تشخیص‌دهنده‌ها رقابتی است که تا ابد ادامه خواهد داشت. یک جورهایی، انگار خود این دو گروه با هم یک GAN عظیم و بی‌پایان می‌سازند!خوب: هوش مصنوعی شبه‌انسانی و تعاملات ارتباطی نوجهان پر از دیپ‌فیک شاید مخوف و ناامن باشد؛ اما این تنها آینده ممکن نیست! دیپ‌فیک کاربردهای مثبتی هم دارد؛ دیپ‌فیک می‌تواند نحوه ارتباطات را دگرگون کند و شکل‌های کاملا جدیدی از آن به وجود بیاورد. به عنوان مثال، تصور کنید فناوری تولید صدا با فناوری دیپ‌فیک ترکیب شود! حتی همین حالا هم دستیار گوگل می‌تواند با استفاده از یک مدل مولد برای تولید گفتار به نام ویو‌نت (Wavenet)، با لحن و صدای جان لجندصحبت کند. استارتاپ‌های لایربرد (Lyrebird)و ماجولیت (Modulate) می‌توانند فقط با چند ساعت آموزش دیدن، یاد بگیرند مثل شما حرف بزنند! حتی فناوری بایدو (Baidu) می‌تواند تنها در 3.‌7 ثانیه صدای افراد را شبیه‌سازی کند. در آینده‌ای نه چندان دور، سخنگوهای هوشمندی خواهیم داشت که نه تنها می‌توانند با صدای خواننده‌های مورد علاقه‌مان صحبت کنند، که بلدند وقتی خودمان سر کار نیستیم، به جای ما جواب تلفن را بدهند!حتی تولید ویدیوهای فیک هم الزاما چیز بدی نیست. شرکت سینتزیا (Synthesia) ، ویدیوی دیپ‌فیکی از دیوید بکهام را برای یک کمپین حمایتی مالاریا تولید کرده است. استارتاپ دیتاگرید (DataGrid) توانسته تصویر کل بدن آدم‌هایی که وجود خارجی ندارند را کامل بسازد، و پژوهشگران دانشگاه برکلی کالیفرنیا با کمک دیپ‌فیک توانسته‌اند حرکات مختلف رقص را روی بدن افراد مختلف اجرا کنند. حتی اخیرا موزه دالی در فلوریدا، به لطف دیپ‌فیک توانسته این هنرمند سوررئالیست اسپانیایی را برای صحبت با بازدیدکنندگان از موزه به دنیا بازگرداند!از ویدیوی دیپ‌فیک سالوادور دالی در موزه دالی فلوریداتصور کنید شخصیت‌های تاریخی‌ای که رویتان تاثیر گذاشته‌اند با شما حرف بزنند. تصور کنید عزیزانی که از دنیا رفته‌اند دوباره به پیشتان برگردند. و اگر هنوز دارید در آرزوی رفتن به دنیای هری‌پاتر می‌سوزید، تصور کنید همه آن پرتره‌های متحرک هاگوارتز واقعا وجود داشته باشند!جمع‌بندیفرنک ابگنیل فیلم «اگه میتونی منو بگیر»، یک شخصیت واقعی است که وقتی سرانجام از زندان آزاد شد، چهار دهه از عمرش را به کار کردن در FBI روی جعل‌، اختلاس، جرم‌های مالی، و جرم‌های امنیت سایبری گذراند. ابگنیل در سخنرانی‌ای در گوگل گفته که «فناوری، زاینده جرم است. همیشه همین بوده و همیشه هم چنین خواهد بود». با اینحال، او می‌گوید که این هکرها نیستند که امنیت اطلاعات شرکت‌ها را پایین می‌آورند؛ بلکه مقصر آن کارمندان سهل‌انگاری در آن شرکت هستند که کاری که قرار نبوده بکنند را کرده‌اند، یا اینکه نتوانسته‌اند کاری که قرار بوده بکنند را انجام دهند.همین اتفاق برای دیپ‌فیک هم می‌افتد: مهم نیست دیپ‌فیک‌ها چقدر واقع‌گرایانه‌تر شوند یا دقت فناوری‌های ضد دیپ‌فیک تا چه حد افزایش پیدا کند؛ آسیب اصلی ناشی از این دیپ‌فیک‌ها کار انسان‌هایی هست که آنها را می‌سازند، ساخته‌های دروغین را باور می‌کنند، و چیزی که بدون تحقیق، درست فرض کرده‌اند را نشر می‌دهند. به جای اینکه انگشت اتهام را به سمت خود فناوری دیپ‌فیک بگیریم، باید ببینیم چطور می‌شود کاری کرد که افراد در مورد چیزهایی که در اینترنت می‌بینند با دید انتقادی‌تری قضاوت کنند و هنگام به اشتراک‌گذاری‌ در شبکه‌های اجتماعی هوشمندانه‌تر عمل نمایند. اثرات منفی دیپ‌فیک را نمی‌شود انکار کرد؛ اما باید چشم‌هایمان را به بخش‌های مثبت‌تر هوش مصنوعی بدوزیم و پتانسیلی که دیپ‌فیک برای ایجاد روش‌های ارتباطی جدید و بهتر کردن زندگی‌هایمان دارد را به مسیر درست هدایت کنیم.اگر به یادگیری کاربردهای هوش مصنوعی برای تحلیل داده علاقه‌مند شدید، پیشنهاد می‌کنیم سری هم به دوره جدید کوئراکالج، یعنی «دوره هوش مصنوعی و یادگیری ماشین» بزنید. این دوره با داده‌های واقعی از شرکت پوشه و تمرین‌های بسیار سر و کار دارد.ترجمه بر اساس: "Deepfake: The Good, The Bad and the Ugly" by Nahua Kang @ Twentybn Mediumکوئرامگ مجله‌ای تخصصی برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید توئیتر یا کانال تلگرام کوئرا را دنبال کنید. مریم مقدس برهان مریم مقدس برهان Sat, 28 Sep 2019 19:20:57 +0330 https://virgool.io/Quera-Mag/%D9%87%D9%88%D8%B4-%D9%85%D8%B5%D9%86%D9%88%D8%B9%DB%8C-%D8%AA%D8%B1%D9%86%D8%AF-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%AF-kgwn29lvavx6 از زمانی که جهان برای اولین بار با هوش مصنوعی آشنا شد، سال‌ها گذشته است. حالا این فناوری نه تنها ابزار دست کسب و کارها شده، که کاربران معمولی هم به راحتی به آن دسترسی دارند.هوش مصنوعی امروزه کمک‌یار همه صنعت‌های جهان شده است. توانایی شگرفی که هوش مصنوعی برای پردازش مجموعه‌داده‌های حجیم و استفاده از آنها برای هدف‌های مختلف دارد، به کسب و کارها کمک کرده تا عملکردشان را به شکل قابل توجهی بهبود ببخشند و بتوانند یک مجموعه‌ خدمات کاملاً جدید به کاربران عرضه کنند.همه ما با دستیارهای مجازی، خانه‌های هوشمند، اپلیکیشن‌های شخصی‌سازی شده، و گجت‌های هوشمند آشنا هستیم. وقتی اولین بار با آنها روبرو شدیم، حسابی حیرت کرده بودیم؛ اما حالا خیلی از آنها را بخش روزمره زندگی‌مان می‌دانیم. اما آیا این اوج چیزی است که هوش مصنوعی می‌تواند عرضه کند؟ یا اینکه آینده این فناوری قرار است باز هم پر از سورپرایز‌های شگفت‌انگیز باشد؟ در ادامه، چندی از پرطرفدارترین کاربردهای هوش مصنوعی در جهان امروز را برایتان معرفی می‌کنم که آینده‌مان را درخشان خواهند کرد.۱. شخصی‌سازی پیشرفتهاین یک حقیقت است: همه کاربرها عاشق شخصی‌سازی هستند! اگر فروشگاه آنلاینی محصولات جدید را بر مبنای خریدهای قبلی مشتریان به آنها پیشنهاد کند، ۵۶% این مشتریان علاقمند خواهند بود که باز هم به این سایت سر بزنند. اگر تبلیغی شخصی‌سازی شده باشد، نرخ CTR آن ده برابر یک تبلیغ عمومی می‌شود. ابزارهای هوش مصنوعی می‌توانند داده‌های مشتریان را جمع‌آوری و پردازش کنند و بر مبنای آنها، محصولات یا خدمات مناسب برای یک شخص بخصوص را پیشنهاد دهند. برای صنعت تجارت الکترونیک که همه چیزش بر محور مشتریان و عادت‌های خرید آنها می‌چرخد، این قابلیت خیلی ارزشمند است.اما فقط تجارت الکترونیک نیست که از شخصی‌سازی با هوش مصنوعی سود می‌برد. پشت اپلیکیشن‌های تناسب اندام پرطرفدار این روزها هم هوش مصنوعی ایستاده است. این اپلیکیشن‌ها می‌توانند با تحلیل عادت‌های کاربر، رژیم غذایی یا تمرینات ورزشی پیشنهاد دهند که اختصاصی به درد شخص خود کاربر بخورد. اصلا چرا به یکی دو حیطه اکتفا کنیم؟ هر کسب‌وکاری با هر موضوعی می‌تواند با هوش مصنوعی کارهای هیجان‌انگیز بکند: کافی است که آن کسب و کار به شخصی‌سازی تجربه مشتری علاقمند باشد.۲. جستجوی تصویریقابلیت جستجوی تصویری پینترستدرست است که این کاربرد نسبتاً قدیمی است، اما هنوز پتانسیل زیادی برای پیشرفت دارد. چند سال قبل، پینترست قابلیت لنز خود را به بازار معرفی کرد (Pinterest Lens). این قابلیت، مثل Shazam برای اشیا بود. کاربر می‌توانست هر شیئی که می ‌خواست را با دوربینش اسکن کند، و بعد نرم‌افزار، اشیای مشابه آن شیء را در پینترست جستجو می‌کرد. حالا دیگر غول‌های صنعت مثل گوگل و مایکروسافت هم امکان جستجوی تصویری را فراهم کرده‌اند و به نظر می‌رسد که این کاربرد هوش مصنوعی حسابی در دنیای نرم‌افزار جا خوش کرده است.با جستجوی تصویری، کاربران می‌توانند در کسری از ثانیه نتایج بسیار دقیقی برای جستجوی خود دریافت کنند. از آنجا که کاربر از قبل می‌داند دقیقاً دنبال چه چیزی است، نتایج دریافتی‌اش صد درصد با چیزی که جستجو کرده تناسب دارند. هر صنعتی می‌تواند از چنین سرویسی سود ببرد، اما حیطه تجارت الکترونیک به طور خاص از همه بیشتر به آن اهمیت خواهد داد.۳. چت‌بات‌ها و دستیارهای مجازیدر آینده خیلی نزدیک، دستیارهای مجازی و بات‌ها گسترش بیشتری پیدا می‌کنند و «باهوش‌تر» می‌شوند. به این ترتیب، کارمندان از شر کارهای حوصله‌سربری مثل جواب دادن به سوال‌های زیادی ساده یا انجام وظایف روتین خلاص خواهند شد.استفاده از بات‌ها نه تنها برای کارمندان رهایی‌بخش است، که باعث صرفه‌جویی در وقت کاربران هم می‌شود. برخلاف انسان‌های واقعی، بات‌ها بلافاصله جواب سوال کاربر را به او ارائه می‌کنند. به این ترتیب، کیفیت تجربه کاربری هم بالا می‌رود، زیرا مشتری می‌تواند اطلاعات بسیار دقیق و صحیح را بدون اینکه مدت‌ها پشت خط منتظر بماند، دریافت کند.بات‌ها به افراد در خرید کمک می‌کنند، خدمات مختلف و محصولات گوناگون را بر مبنای نیاز فردی کاربر برای او انتخاب می‌کنند، سفارش آنها را می‌گیرند، و وضعیتشان را تعقیب می‌کنند. در زمینه دستیارها هم باید بگویم که همین حالا هم آمازون دستیار خرید الکسا را به بازار معرفی کرده است. به زودی ممکن است عده بیشتری از این کمک‌یارهای مجازی را هم ببینیم و آنها با انجام طیف وسیعی از کارها، زندگی ما را آسان‌تر ‌کنند.۴. تحلیل‌های پیشگویانه در دنیای دیجیتال امروز، همه برنامه‌ها به داده‌ها متکی هستند. داده‌های مشتری معدنی از طلاست: پر از بینش در مورد رفتارهای مشتری هنگام خرید و پیش‌بینی تصمیمات آینده وی. ولی تحلیل پیشگویانه (Predictive Analytics) چیزی فراتر از پیش‌بینی خریدهای بعدی مشتریان است. لازم نیست به آینده فکر کنیم؛ همین حالا هم در صنعت پزشکی، تحلیل‌های پیشگویانه به تخمین زدن احتمال بیماری در آینده کمک می‌کنند. حتی در دنیای حسابداری می‌شود اعتبار و شهرت قرض‌گیرنده‌ها را با همین نوع تحلیل‌ها سنجید.به خاطر ارزش افزوده‌ای که تحلیل‌های پیشگویانه برای صنایع دارند، در آینده خیلی نزدیک شاهد توسعه فعالانه‌تر این تحلیل‌ها خواهیم بود. آنها به کسب و کارها کمک خواهند کرد تا استراتژی‌های قابل اتکاتر و قابل اعتمادتری پیش بگیرند و درآمدشان را هم به شکل قابل توجهی بالا ببرند.۵. تشخیص چهرهرباتی که با فناوری تشخیص چهره، شخصیت «والدو» را از بین همه این شخصیت‌ها با دست نشان می‌دهد!اخیراً فناوری تشخیص چهره بازتاب‌های منفی در رسانه‌ها داشته‌ است. به عنوان مثال خبرهای مربوط به Deepfake که این روزها نگرانی‌های زیادی را در سطح افکار عمومی ایجاد کرده یکی از آن‌هاست. (و اگر فکر می‌کنید می‌توانید ویدئوهای تقلبی ساخته‌شده توسط هوش‌مصنوعی را از ویدئوهای واقعی تشخیص دهید، کافی است این لینک را نگاهی بیندازید!)اما این فناوری در این سال و سال‌های آتی به رشد خود ادامه خواهد داد. فناوری تشخیص چهره، یک تکنیک هوش مصنوعی است که با آن می‌شود با مقایسه الگوی مشخصات چهره‌ای افراد با عکس دیجیتالشان، آنها را شناسایی کرد.در سال پیش رو، کلی استفاده‌ جدید برای فناوری تشخیص چهره خواهیم دید و خیلی از آنها دقت و اعتبار خیلی بالاتری هم پیدا خواهند کرد. به عنوان مثال، برنامه دیپ‌فیس (Deepface) فیس‌بوک که با آن اعضای خانواده و دوستانتان را در عکس‌ها تگ می کردید، حسابی رشد خواهند کرد. امروزه دیگر هر گوشی هوشمندی که به بازار می‌آید یک قفل چهره هم دارد؛ این قفل‌ها هم در تشخیص تفاوت چهره شما و خواهر و برادرتان تواناتر خواهند شد!استفاده از فناوری تشخیص چهره برای شناسایی بیومتریکی به این زودی‌ها قرار نیست از میان برود؛ از تبلیغات گرفته تا ارسال محموله‌های کالا برای استفاده از این فناوری جا دارند. استفاده از قابلیت تشخیص چهره برای کاربرها آسان است و به شکل غیرتهاجمی هم انجام می‌شود؛ بنابراین هر روز بیشتر از دیروز به رشد خود ادامه خواهد داد.از دیگر جاهایی که می‌توان فناوری تشخیص چهره را در آنها به کار برد، پردازش پرداخت‌ها از طریق بررسی‌های امنیتی و قانونی است. در شاخه پزشکی هم می‌توان از آن برای آزمایش‌های بالینی و تشخیص‌های پزشکی استفاده کرد. اوپن‌واتر (Openwater) که یکی از فناوری‌های تصویربرداری پزشکی قابل حمل است، دارد مرزهای عکس‌برداری از مغز را در می‌نوردد.۶. هم‌گرایی هوش مصنوعی و بلاک‌چینهمه ما می‌دانیم که تکنولوژی بلاک‌چین با مشکلاتی همچون ناتوانی در مقیاس‌پذیری (Scalability) روبرو است. از آن طرف، هوش مصنوعی هم با مسائل مربوط به اعتماد و حریم خصوصی سر و کله می‌زند. اما اگر این دو فناوری با هم ترکیب شوند، می‌توانند به کمک هم از پس این چالش‌ها بربیایند.با ایجاد فروشگاه‌های غیرمتمرکز، بلاک‌چین می‌تواند به قابل اعتماد بودن و شفافیت الگوریتم‌های هوش مصنوعی کمک کند. به عنوان مثال، انیگما (Enigma) استارتاپی است که فروشگاه امنی برای داده‌ها فراهم می‌کند، و کاربران می‌توانند از طریق قراردادهای هوشمند Subscribe کرده و به این داده‌ها دسترسی داشته باشند.۷. ورود تراشه‌های مناسب هوش مصنوعی به بازارهوش مصنوعی پردازنده‌های مخصوصی می‌خواهد که عملکرد CPU را تکمیل کنند. مدل‌های پیشرفته CPU نمی‌توانند سرعت مدل‌های یادگیری هوش مصنوعی را افزایش دهند. اگر قرار است مدل هوش مصنوعی بتواند با حل مسئله‌های پیچیده ریاضی، سرعت تشخیص چهره و اشیا را بالا ببرد، باید سخت‌افزارهای اضافه‌ای داشته باشد.تولیدکنندگان تراشه مثل ان‌ویدیا (Nvidia)، آرم (ARM)، اینتل (Intel)، و کوالکام (Qualcomm) تراشه‌های مخصوصی خواهند ساخت که بتواند سرعت اپلیکیشن‌های هوش مصنوعی را افزایش دهد. (AI-enabled Chips) این تراشه‌های خاص بسته به نوع کارکردی که قرار است داشته باشند، متفاوت خواهند بود؛ مثلا تراشه‌های مناسب برای پردازش زبان‌های طبیعی یا تشخیص گفتار با تراشه‌های بینایی رایانه‌ای فرق خواهد داشت. اپلیکیشن‌های صنعتی به زودی قرار است برای ارائه خدمات هوش مصنوعی به کاربرانشان به این تراشه‌ها متکی شوند.۸. هم‌گرایی هوش مصنوعی و اینترنت اشیادر سال‌های پیش رو، هوش مصنوعی و اینترنت اشیا در دنیای محاسبات لبه‌ای (Edge Computing) به هم خواهند رسید. همین حالا هم نمونه‌هایی از هم‌گرایی این دو فناوری را داشته‌ایم؛ به عنوان مثال، اگر اینترنت اشیا و هوش مصنوعی با هم ترکیب نمی‌شدند ما نمی‌توانستیم ماشین خودران بسازیم. اما این دو فناوری هنوز پتانسیل‌های کشف نشده زیادی برای همکاری دارند. سنسورهای اینترنت اشیا می‌توانند داده‌های هر لحظه را جمع‌آوری کنند و مدل‌های هوش مصنوعی می‌توانند امکان تصمیم‌گیری اتوماتیک با این داده‌ها را فراهم نمایند. علاوه بر این، الگوریتم‌های یادگیری عمیق (Deep Learning) هم کمک می‌کنند تا تصمیماتی که بر مبنای داده‌های سنسورها گرفته شده، به اقدامات عملی تبدیل شوند. بعضی از این اقدامات عبارتند از تعقیب حرکت چشم برای نظارت بهتر بر راننده، مشخص کردن مسیر، حرکت اتوماتیک به سمت پمپ بنزین در صورت کم شدن بنزین، یا پردازش زبان‌های طبیعی برای دریافت فرمان‌های صوتی.اینترنت اشیا حالا دیگر آماده است تا هوش مصنوعی را به جلو براند. خدمات لبه‌ای به تراشه‌های مخصوص هوش مصنوعی مجهز خواهند شد که بر پایه ASIC و FPGA ساخته شده‌اند.۹. سیاست‌گذاری و حریم خصوصییادتان هست که پارسال ناگهان اینباکس‌مان پر از خروار خروار ایمیل‌های سایت‌ها در مورد تغییر Privacy Policy شد؟ همه آن تغییرها بخاطر اجرایی شدن مقررات عمومی حفاظت از داده اتحادیه اروپا (GDPR) بود که یکی از داغ‌ترین خبرهای سال تلقی می‌شد. امسال و سال بعد هم قرار است اخبار بیشتری در مورد سیاست‌گذاری و حریم خصوصی بشنویم.اغلب ما هنوز هم نمی‌دانیم که اطلاعات دیجیتالمان در سطح اینترنت چگونه نگهداری می‌شود. با این حال، بحران بزرگ حریم خصوصی فیس بوک باعث شد که در مورد خصوصی ماندن داده‌های دیجیتالمان کمی هشیارتر شویم. برای همین هم مسئله سیاست‌گذاری برای حریم خصوصی، در سال‌های آتی همچنان یکی از دغدغه‌های اساسی دولت‌ها و قانون‌گذاران خواهد بود. با افزایش روزافزون استفاده شرکت‌های نرم‌افزاری از هوش مصنوعی، مسئله رضایت افراد از استفاده شرکت‌ها از داده‌های هوش مصنوعی‌شان، اهمیت بسیار زیادی پیدا خواهد کرد. قوانین فعلی در مورد هوش مصنوعی نیاز به بازبینی پیدا خواهند کرد و در سرتاسر دنیا، کشورها به تلاششان برای وضع مقررات برای اپلیکیشن‌های هوش مصنوعی ادامه خواهند داد.۱۰. مسائل اجتماعی‌اقتصادیحالا که هوش مصنوعی هر روز محبوب و محبوب‌تر می‌شود، یک سوال واحد ذهن همه را به خود مشغول کرده است: آیا هوش مصنوعی قرار است روزی شغل‌های مختلف را به کلی از میان ببرد؟جواب این است که بستگی دارد. هرجا که منابع موجود محدود باشند، هوش مصنوعی جای مشاغل مختلف را خواهد گرفت؛ اما در عین حال مشاغل جدیدی ایجاد می‌کند که هرکدام به مجموعه مهارت‌های مختلفی نیاز دارند. همچنین حتی اگر خودکار کردن فرآیندها نیاز به برخی مشاغل را از بین ببرد، باز هم بعضی شغل‌ها هستند که همیشه برای جامعه لازم خواهند بود؛ مثل معلمی، مراقبت و پزشکی، و خدمات مشتریان.پاسخ درست به این سوال هرچه که باشد، ذهن دولت‌های مختلف و مجمع جهانی اقتصاد را حسابی به خود مشغول کرده است. بحث‌های داغی سر این قضیه در این مجامع جریان گرفته است، چون این نگرانی وجود دارد که با ظهور اپلیکیشن‌های هوش مصنوعی، اختلاف بین میزان مهارت‌های افراد و میزان مهارت‌های مورد نیاز برای مشاغل بیشتر از قبل شود و جوامع به سمت دوقطبی شدن بروند. قانون‌گذارانی که به دنبال راه حل برای این مشکل هستند، در سال‌های آتی بر برنامه‌های بازتوزیعی تمرکز خواهند کرد.جمع‌بندیبه نظر می‌رسد استفاده از هوش مصنوعی برای تحلیل داده‌ها و ارائه خدماتی شگفت‌انگیز به کاربران، هر روز در حال افزایش است. نه تنها استفاده از هوش مصنوعی کمتر نخواهد شد، که با گذشت زمان تعداد زیادی ترند جدید هم برای این فناوری خواهیم دید که یکی از یکی هیجان‌انگیزترند! بخصوص در دنیای توسعه موبایل، بعضی از پیشروان صنعت معتقدند که هوش مصنوعی یکی از آن فناوری‌هایی خواهد شد که هر شرکت اپلیکیشنی باید حتماً آن را داشته باشد؛ یعنی همانقدر رایج شود که خدمات ابری امروز هستند. انگار بیراه هم نمی‌گویند؛ به نظر می‌رسد که ستاره اقبال هوش مصنوعی به این زودی‌ها قصد افول ندارد.ترجمه بر اساس:"Ten Trending Applications of Artificial Intelligence" by LeewayHertz @ Hackernoon"AI Trends for 2019: What Should We Expect?" by Natalia Kukushkina @ Hackernoon? اگر به یادگیری کاربردهای هوش مصنوعی برای تحلیل داده علاقه‌مند شدید، پیشنهاد می‌کنیم سری هم به دوره جدید کوئراکالج، یعنی «دوره هوش مصنوعی و یادگیری ماشین» بزنید. این دوره که با داده‌های واقعی و تمرین‌های بسیار سر و کار دارد، الآن در مرحله پیش‌ثبت‌نام رایگان قرار دارد. مریم مقدس برهان مریم مقدس برهان Fri, 06 Sep 2019 16:42:52 +0430 https://virgool.io/Quera-Mag/%D8%AA%D8%A7%D8%B1%DB%8C%D8%AE%DA%86%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-%D9%87%D8%A7%DB%8C-%D9%85%D9%87%D9%85-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-bbxhn37hfgnl اگر روزی خواستید میان گروهی از برنامه‌نویس دعوا بیندازید، کافی است سوال بالا را در جمع‌شان مطرح کنید و بعد یواشکی در بروید! تخمین زده‌اند که در دنیا بین ۵هزار تا ۲۵هزار زبان برنامه‌نویسی وجود دارد، اما به نظر اغلب برنامه‌نویس‌ها فقط یک زبان برتر است و آن هم زبانی است که خودشان با آن کد می‌زنند! در این پست می‌خواهم یکی از بهترین پاسخ‌های دنیا به این سوال را با شما در میان بگذارم و یک بار برای همیشه قائله را ختم کنم (البته اگر قبل از آن در کامنت‌ها جنگ به پا نکنم!). این جوابی است که یک کاربر خردمند به نام دیمیتری زاگیدولین در Quora به این سوال داده‌ است. به نظر او، سه گروه هستند که می‌توانند مدال تاثیرگذارترین زبان‌های برنامه‌نویسی دنیا را با افتخار دور گردنشان بیندازند: مادربزرگ‌های زبان‌ها، شکل‌دهنده‌های دنیای برنامه‌نویسی معاصر، و غول‌های جهان امروز!مادربزرگ‌های زبان های برنامه نویسیاین گروه، آنهایی هستند که به نحوه‌ی طراحی زبان‌های برنامه‌نویسی جهت دادند و خودشان زبان‌هایی را به دنیا آوردند که دنیای برنامه‌نویسی مدرن با آنها ساخته شده است. حتی اگر این زبان‌ها مستقیماً استفاده نشوند، رد پایشان در همه زبان‌های جدید دیده می‌شود. همه این زبان‌ها بسیار تاثیرگذار بوده‌اند؛ بدون این مادربزرگ‌ها، امروز هیچ اثری از زبان‌های جوان برنامه نویسی مدرن نبود.خط سیر پیدایش زبان های برنامه نویسی در طول تاریخ و ارتباط زبان‌ها با یکدیگرتصویر بالا از وبسایت AI Study مروری بر خانواده زبان‌های برنامه‌نویسی دارد. برای نموداری حتی مفصل‌تر می‌توانید این تصویر از وبسایت DigiBarn را ببینید!۱. اسمبلی (Assembly)قبل از ساخته شدن اسمبلی، برنامه‌نویسی مستقیما با صفر و یک انجام می‌شد. مثلاً اگر می‌خواستید دستور اضافه کردن چیزی را بنویسید، باید یادتان می‌بود که دستور 12 یعنی اضافه کردن. زبان اسمبلی با جایگزین کردن کلمات نمادین به جای صفر و یک‌ها، برنامه‌نویسی را راحت‌تر کرد؛ یعنی به جای دستور 12، فقط لازم بود کلمه ADD را بنویسید. اسمبلی نقطه آغاز این نگرش بود که وقت و راحتی برنامه‌نویس، خیلی مهم‌تر از وقت و راحتی کامپیوتر است!همه بازی‌های کنسول آتاری، نینتندو، سگا و... با اسمبلی نوشته شده‌اند. MS-DOS و لوتوس 1-2-3 (پدربزرگ اکسل) و نرم‌افزار سفینه ماه‌نشین آپولو هم همگی از دستاوردهای کار با اسمبلی هستند.۲. فورترن (Fortran)فورترن که در دهه ۱۹۵۰ در IBM ساخته شده بود، یکی از اولین زبان‌های برنامه‌نویسی است. فورترن یکی از پراستفاده‌ترین زبان‌هاست و حتی امروز هم همچنان نقش مهمی در دنیای برنامه‌نویسی ایفا می‌کند. می‌شود گفت همه زبان‌های برنامه‌نویسی ما مثل کوبول (Cobol)، لیسپ (Lisp)، سی (C)، اسمال‌تاک (Smalltalk)، جاوا (Java) و غیره از فورترن ریشه گرفته‌اند. فورترن از بسیاری جهات پیشرو دوران بود: مثلاً در مطرح کردن مفهوم کامپایلر، زبان‌ برنامه‌نویسی عمومی، و محاسبات علمی. همچنان که در مقاله ویکی‌پدیای آن آمده، این زبان هنوز هم استفاده‌های مهمی دارد: «فورترن مهم‌ترین زبان برای انجام ابرمحاسبات گسترده مثل مدل‌سازی وضعیت هوایی و اقلیمی، دینامیک سیال محاسباتی، شیمی محاسباتی، اقتصاد محاسباتی، دام‌پروری، اصلاح نباتات، و فیزیک محاسباتی است.»۳. لیسپ (Lisp)باورتان می‌شود که لیسپ در سال ۱۹۵۸ اختراع شده؟! لیسپ سرچشمه بسیاری از نوآوری‌ها در تحقیقات هوش مصنوعی بوده، خیلی از برنامه‌نویسان بزرگ دوران با آن آموزش دیده و رشد کرده‌اند، و حتی امروز هم برخی استارتاپ‌های مهم از آن در قالب زبان‌هایی مثل کلوژر (Clojure) استفاده می‌کنند. ساختار منطقی if-then-else که امروزه در همه زبان‌های برنامه‌نویسی مدرن حضور دارد، برای لیسپ اختراع شده بود. بازیافت حافظه یا زباله‌روبی (Garbage collection) هم اولین بار در لیسپ وجود داشت. لیسپ بود که باعث شد مفهوم برنامه‌نویسی تابعی (مثل List Comprehension در پایتون، نگاشت‌کاهش و...) در همه جا اینطور گسترده به کار برود. زبان‌های برنامه‌نویسی زیادی هستند که از لیسپ تاثیر گرفته‌اند؛ از جمله اسمال‌تاک (که ++C از آن تاثیر گرفته)، جاوا، روبی (Ruby)، پایتون و جاوا اسکریپت.ادیتور ایمکس (Emacs) با لیسپ ساخته شده است. فروشگاه ویاوب (Viaweb) که بعدا به Yahoo Stores تبدیل شد و موتور جستجوی پروازهای ارزان‌قیمت ITA که اوربیتز (Orbitz) و کایاک (Kayak) از آن استفاده می‌کنند هم با لیسپ نوشته شده‌اند. نرم‌افزار کنترل از راه دور کاوشگر Deep Space 1 ناسا هم زبانش لیسپ بود. چه کسی می‌داند، حتی شاید کل جهان هستی هم با لیسپ ساخته شده باشد!کمیکی از xkcd درباره اثرگذاری زبان‌ Lisp۴. سیمولا (Simula)به لطف سیمولا بود که دنیای نرم‌افزار با مفهوم برنامه‌نویسی شیءگرا آشنا شد. Objectها، Classها، Inheritance، و دیگر مفاهیم شیءگرا همه ریشه در سیمولا دارد. سیمولا سرچشمه همه زبان‌های شی‌ءگرا مثل اسمال‌تاک، سی‌پلاس‌پلاس، سی‌شارپ، جاوا و جاوا اسکریپت است.۵. اسمال‌تاک (Smalltalk)اسمال‌تاک خودش از سیمولا نشأت گرفته، اما در زمان خودش انقلابی در دنیای برنامه‌نویسی ایجاد کرده بود و حتی هنوز هم از خیلی نظرها بی‌همتاست. به خاطر بازاریابی بد و رقابت داخل‌شرکتی، اسمال‌تاک آنطور که باید رواج پیدا نکرد، اما حالا به خاطر پروژه‌های وب و متن‌باز اسکوئیک (Squeak) و فارو (Pharo)، کمی دوباره مطرح شده است.جاوا، آبجکتیو سی، سی‌شارپ، و جاوا اسکریپت (از طریق سلف (Self))، همگی مستقیماً از اسمال‌تاک تاثیر گرفته‌اند. روبی (Ruby) هم که یکی از محبوب‌ترین زبان‌های این روزهاست، نه تنها از اسمال‌تاک تاثیر گرفته که از نظر فلسفی از همه زبان‌های دیگر به آن شبیه‌تر است.زبان‌های برنامه‌نویسی شکل‌دهنده‌ی دنیای معاصراین زبان‌ها آنهایی هستند که بخش عظیمی از تمدن و اقتصاد امروز ما بر پایه آنها ساخته شده است. بسیاری از غول‌های بزرگ دنیای وب و اقتصاد که موقع استفاده ازشان حتی فکر هم نمی‌کنیم، دستاورد این زبان‌ها هستند!۱. زبان‌های C و ++Cزبان C آنقدر تاثیرگذار بوده که اصلاً نمی‌شود گستره تاثیر آن را راحت مشخص کرد. همه سیستم‌عامل‌هایی که استفاده می‌کنیم (ویندوز، یونیکس/لینوکس، اندروید، سیستم عامل اپل) همگی به C یا یکی از زبان‌های مشتق شده از آن نوشته شده‌اند. برنامه‌های آفیس مایکروسافت بر پایه‌ی ++C و #C هستند. فایرفاکس موزیلا با سی‌پلاس‌پلاس نوشته شده است. بخش زیادی از کدهای Mission-critical گوگل (مثلا بخش زیادی از بک‌اند جی‌میل) به زبان سی‌پلاس‌پلاس هستند. حتی اغلب بازی‌های کامپیوتری مشهور هم با سی یا سی‌پلاس‌پلاس نوشته شده‌اند.سی در به وجود آمدن کلی از زبان‌های پرطرفدار دیگر هم نقش داشته است. سی‌پلاس‌پلاس، آبجکتیو سی، سی‌شارپ، جاوا، و جاوا اسکریپت همگی از سی تاثیر گرفته‌اند.۲. کوبول (COBOL)کوبول زبان برنامه‌نویسی بانک‌ها و دولت‌هاست. برای اینکه متوجه شوید چه حجم زیادی از نرم‌افزارهای حیاتی دنیا با کوبول نوشته شده‌اند، بروید و در مورد بحران سال ۲۰۰۰ یا بحران Y2K سرچ کنید. از آنجا که اغلب برنامه‌ها سال چهار رقمی را فقط با دو رقم آخر نمایش می‌دادند، سال 2000 قرار بود به شکل 00 نشان داده شود که با طرز نمایش سال 1900 یکی بود. این مسئله کلی باگ مختلف در سیستم‌‌های کامپیوتری ایجاد می‌‌کرد و حتی خیلی‌ها فکر می‌کردند قرار است دنیا به خاطر آن به آخر برسد! سیستم‌هایی که این موضوع در موردشان مطرح بود، همگی سیستم‌های کوبول بودند. مقاله ویکی‌پدیا در باب اهمیت کوبول می‌گوید که «در سال ۱۹۹۷، گروه گارتنر (Gartner Group) گزارش کرد که هشتاد درصد کسب و کارها در جهان با کوبول جلو می‌روند، بیش از ۲۰۰میلیارد خط کد با آن نوشته‌اند، و تخمین زده می‌شود که سالانه پنج میلیارد خط کد جدید تولید ‌کنند.»۳. پی‌اچ‌پی (PHP)پی‌اچ‌پی و پرل (Perl) بودند که جهان وب (World Wide Web) را ساختند. پی‌اچ‌پی را راحت می‌شد یاد گرفت و استفاده کرد، و پیدا کردن هاستی که از پی‌اچ‌پی پشتیبانی کند هم هزینه چندانی نداشت. خیلی از سایت‌هایی که از قدیم آنها را می‌شناسید، با پی‌اچ‌پی نوشته شده‌اند؛ مثل فیس‌بوک، وردپرس، ویکی‌پدیا و همچنین بخش زیادی از یاهو، لینکدین، فلیکر و تامبلر.غول‌های برنامه نویسی جهان امروزگروه بالا هم کم از غول بودن نداشتند؛ اما قدیمی‌تر بودند و برنامه‌های ساخته شده با آنها محدود. زبان‌های زیر، غول‌هایی هستند که اختیار دنیای برنامه‌نویسی امروز را کامل به دست گرفته‌اند.نمودار معروف گیت‌هاب از پرکاربردترین زبان های برنامه نویسی جهان۱. جاوا (Java)بسیاری از نرم‌افزارهای تجاری (مثلا بورس سهام آمریکا) با جاوا ساخته شده‌اند. بخش اعظم گوگل و کل سیستم آمازون با جاوا اجرا می‌شوند. سیستم عامل محبوب اندروید هم با جاوا نوشته شده است. جاوا در همه جا حاضر است: در پایگاه‌های داده بانک‌ها، ابررایانه‌های مورد استفاده در تحقیقات، تلویزیون‌ها و گوشی‌های هوشمند.در طی بیش از دو دهه، میلیاردها دلار صرف بهینه‌سازی ماشین مجازی جاوا (JVM) و اکوسیستم نرم‌افزاری آن شده است. حالا که سرعت این زبان به حد سی‌پلاس‌پلاس رسیده، زبان‌های بسیاری غیر از خود جاوا هم به بایت‌کد JVM کامپایل می‌شوند و به این ترتیب، جاوا هر روز تاثیرگذارتر از دیروز می‌شود. زبان‌های مبتنی بر JVM عبارتند از کلوژر(Clojure؛ گویشی از لیسپ)، اسکالا (Scala)، جایتون (Jython)، جِی‌روبی (JRuby)، و راینو (Rhino؛ نوعی جاوا اسکریپت سمت سرور)۲. آبجکتیو سی (Objective-C)آبجکتیو سی ترکیب عظیمی از سی و اسمال‌تاک است. دلیلی که آبجکتیو سی را هم در این لیست آورده‌ایم، این است که آیفون، آیپد، و سیستم عامل مک ۱۰ همگی با آن توسعه داده شده‌اند.۳. جاوا اسکریپت (JavaScript)جاوا اسکریپت سمت فرانت جهان وب (World Wide Web) را اجرا می‌کند. آن ویژگی‌های دینامیک و تر و تمیزی که در سایت‌هایی مثل Quora، جی‌میل و فیس‌بوک می‌بینید، همگی دستاوردهای جاوا اسکریپت هستند. در این سال‌ها خیلی‌ها در مورد جاوا اسکریپت برداشت‌های اشتباه کرده‌اند، اما این زبان هم بسیار قدرتمند هم خیلی شکیل است. از نظر سینتکس، جاوا اسکریپت از سی منشا گرفته اما از منظر فلسفی مبتنی بر سلف (Self) است. خود سلف هم ریشه در اسمال‌تاک دارد. از جاوا اسکریپت کم‌کم در سمت سرور هم استفاده می‌شود (مثلا در فریم‌ورک Node.js). استیو یگه (Steve Yegge) که از بلاگرهای قدیم دنیای برنامه‌نویسی و از کارمندان ارشد آمازون، گوگل و گرب بوده، معتقد است که جاوا اسکریپت در آینده بزرگ‌ترین زبان برنامه‌نویسی خواهد بود.۴. روبی (Ruby) و پایتون (Python)اغلب استارتاپ‌های وب آمریکا از این دو زبان استفاده می‌کنند؛ زیرا روبی و پایتون نه تنها انعطاف و پویایی بالایی دارند، که از فریم‌ورک‌های توسعه وب شگفت‌انگیزی مثل ریلز (Rails؛ برای روبی) و جنگو (Django؛ برای پایتون) هم بهره‌مند هستند. در کنار جاوا و سی‌پلاس‌پلاس، پایتون یکی از زبان‌های اصلی مورد استفاده در گوگل است. همچنین پایتون در حیطه مهمی همچون بیوتکنولوژی/بیوانفورماتیک هم به شکل گسترده به کار می‌رود. روبی هم دارد کم کم به دنیای تجارت و بانکداری راه پیدا می‌کند. توییتر محبوبی که هر روز در آن ول می‌چرخیم، با روبی نوشته شده است.به نظر من، این دسته‌بندی منطقی‌ترین و جامع‌ترین جوابی بوده که تا به حال برای این سوال دیده‌ام. نظر شما چیست؟ با آن موافقید یا مخالف؟ چه زبانی بوده که به نظرتان باید حتماً در این لیست جای می‌گرفت و نگرفته؟ چه زبان‌هایی به نظرتان شایستگی حضور در این لیست را نداشتند؟ منتظر شنیدن نظرهایتان هستم! مریم مقدس برهان مریم مقدس برهان Tue, 03 Sep 2019 17:26:02 +0430 https://virgool.io/Quera-Mag/%D8%B1%D8%A7%D9%87%D9%86%D9%85%D8%A7-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%AF%D9%88-%D9%86%D9%81%D8%B1%D9%87-gjbro9j0vxbp راب آیزنبرگ، هکرنون -- عرق سرتا پایم را گرفته بود؛ مغزم با دستپاچگی داشت ناله می‌کرد که «آخه چرا یه دست لباس اضافه با خودت نیاوردی؟» چیزی نمانده بود اضطراب کار دستم بدهد و بدنم را به کلی از کار بیندازد. مانیتورها به من زل زده بودند و دو کیبورد نشسته در بغل هم، با تمسخر به من پوزخند می‌زدند. به نظر مغز پر از آدرنالین من، همین الان بود که بیایند و به خاطر بی‌کفایتی ذهنی و عجز تمام و کمالم در برنامه‌نویسی با تیپا به بیرون پرتم کنند. همکارم کنارم نشست؛ اصلا برای دیدن قیافه‌اش آمادگی نداشتم. قیافه اش هیجان‌زده اما آرام بود. ولی من چی؟ من داشتم بالا می‌آوردم.این روز، ۱۴ آوریل ۲۰۰۸ بود: روزی که من برای اولین بار برنامه نویسی دونفره (Pair Programming) را تجربه کردم. از آن روز تاکنون، سال‌ها گذشته و در این مدت من بارها و بارها جلسات برنامه‌نویسی دونفره را از سر گذرانده‌ام. شاید باورتان نشود، ولی حالا عاشقش هستم. درست است که بعضی‌وقت‌ها زیر فشار تنش و هیجانش له می‌شوی، اما خیلی وقت‌ها هم شب وقت رفتن به خانه، یک خروار حس رضایت زیر بغلت داری.اگر عادت دارید تنهایی کد بزنید، ممکن است فکر کنید که زل زدن دو نفر در کنار هم به یک کد یکسان عجب کار مسخره‌ای است. این بدبینی‌ای که دارید را تحسین می‌کنم (بلاخره کمی شکاکی در زندگی مفید است‌!) اما من معتقدم که وقتی پای یادگیری یک مهارت جدید (مثلا برنامه‌نویسی دونفره) در میان باشد، بهتر است قبل از هر قضاوتی اول به خودمان اجازه بدهیم تا کمی با این مهارت جدید بازی‌ کرده و این تجربه نو را حداقل یک بار از سر بگذرانیم. وقتی آن را بدون سوگیری تجربه کردیم، می‌توانیم به ذهن تحلیل‌گر و منتقدمان اجازه بدهیم تا برگردد و در مورد ارزشمند بودن یا نبودن آن تجربه برایمان سخنرانی کند.اگر با من موافقید و آماده تجربه بی‌قضاوت هستید، می‌خواهم برایتان از برنامه‌نویسی دو نفره بگویم. می‌خواهم برایتان بازگو کنم که چه آموخته‌هایی با سختی کشیدن در این راه به دست آورده‌ام. امیدوارم که چه تازه‌کار باشید و چه کهنه‌کار، بتوانید از آنها بهره ببرید.اصول اولیه برنامه نویسی دو نفرهنقش‌ها را از یاد نبرید. هر دو نفری که می‌خواهند با هم برنامه‌نویسی کنند، خودشان باید کشف کنند که چطور با هم کار کنند نتیجه‌بخش‌تر است. اما معمولا در برنامه‌نویسی‌های دونفره، یک نفر راننده است و دیگری نقشه‌خوان؛ کیبورد دست راننده است: اوست که برای پیاده کردن Feature مورد نظر کد می‌زند. در عوض نقشه‌خوان مسئولیت تفکر استراتژیک در مورد جهت کلی مسیر را به عهده دارد. خوب است که هر سی چهل دقیقه، این دو نفر نقش‌هایشان را با هم عوض کنند.نقشه‌خوان خوبی باشید. کار نقشه‌خوان، پیدا کردن مشکلاتی است که به ذهن راننده خطور نکرده‌اند. آیا تستی را جا انداخته‌ایم؟ کدِ آماده‌ای هست که همین کارکرد مورد نظرمان را انجام دهد؟ رویکرد ساده‌تری هم برای پیش‌برد کار وجود دارد؟ به عنوان نقشه‌خوان، شما نگهبان کیفیت کار هستید و این کار کمی نیست. شجاعت بخصوصی می‌خواهد که درست همان لحظه‌ که همکارتان به خاطر خستگی می‌خواهد تستی را بی‌خیال شود یا کاری را انجام ندهد، با ملایمت بر حفظ کیفیت پافشاری کنید.در برنامه نویسی دو نفره، نقش‌ها یکسان نیست! یکی نقش راننده را ایفا می‌کند و دیگری نقشه‌خوان.حواستان را کاملاً به کار بدهید. دو نفره کار کردن آنقدرها هم آسان نیست؛ هم انرژی زیاد می‌خواهد و هم نظم فراوان. هر دو طرف باید خود را به تولید کد باکیفیت متعهد کنند. این یعنی از زیر کار در رفتن، چک کردن توییتر و ایمیل، و وب‌گردی در گوشی تعطیل. حواستان را کاملاً به کار پیش رو بدهید.وقفه‌های مضر را به حداقل برسانید. هر وقفه و حواس‌پرتی، جریان کار شما را کند می‌کند و زمان خواهد برد تا بتوانید به آن تمرکز اولیه برگردید. هر چیزی که قرار است در کارتان وقفه بیندازد (مثل ایمیل، نوتیفیکیشن‌ها، نورهای چشمک‌زن، صداها) را خاموش کنید، کنار بگذارید، اصلاً بسوزانید! اگر پیام مهمی قرار است بگیرید و نگرانید که مبادا از آن غافل شوید، برای خودتان یادآور بگذارید: آن هم فقط یکی، و ترجیحاً نه با گوشی و لپتاب، بلکه با یک ساعت مچی زنگ‌دار. البته باید این را هم بگویم که هر حواس‌پرتی‌ای هم بد نیست. (قسمت سرعت شخصی در مقابل سرعت جمعی را در ادامه مطلب ببینید!)در مورد استایل کدزنی با هم به تفاهم برسید. وقتی استایل کدها مشخص باشد و همه مدام آن را رعایت کنند، هرکدام از اعضای تیم می‌تواند به سادگی از همان وسط پروژه وارد کار شود. وقت و انرژی‌تان را سر بحث درباره جای آکولادها هدر ندهید؛ به جای آن، اول کار با هم سر یکی از راهنماهای استایل کدزنی که واضح و مشخص هم باشد، توافق کنید (مثل راهنمای استایل Ruby). حالا می‌توانید بروید و وقتتان را سر حل مسئله‌هایی بگذارید که واقعاً مهم هستند! حتی بهتر از آن، چک‌کننده‌های اتوماتیک استایل را روی پروژه‌تان فعال کنید؛ به عنوان مثال: Hound CI از Rubocop ،thoughtbot و همکاران.از هول حلیم توی دیگ نیفتید. توی فیلم‌ها، توسعه‌دهنده‌ها قهرمانانی هستند که با آخرین سرعت دیوانه‌وار تایپ می‌کنند و اگر دود از کیبوردشان بلند نشود، در کمتر از چند ثانیه می‌توانند راه حل هر مشکلی را پیدا کنند! اما ما آدم‌های واقعی اگر اینطوری کار کنیم، تنها چیزی که تولید خواهیم کرد یک توده‌ی بی‌خود مناسب برای انداخته شدن به سطل آشغال خواهد بود. برنامه‌نویسی سریع تایپ کردن نیست، عمیق فکر کردن به مسئله‌های پیچیده است. آسه‌آسه جلو رفتن اما کار را درست انجام دادن بهتر از عجله کردن و پر از غلط پیش رفتن است. لابد می‌گویید پس ددلاین‌ها چی؟ هر چیزی با تمرین بهتر می‌شود. کافیست خودتان را عادت بدهید به درست کار کردن و اطمینان داشته باشید که سرعت هم به مرور زمان سراغتان خواهد آمد.بلند فکر کنید. چه ایده‌ای در سر دارید؟ چرا فکر می‌کنید این روش بهتر از آن یکی روش جواب می‌دهد؟ وقتی افکارتان را به زبان بیاورید، همکارتان از آنها آگاه می‌شود و فرصتی برای همکاری و کمک به شما پیدا می‌کند. علاوه بر این، بلند فکر کردن کمک می‌کند تا خودتان هم مسئله‌های خودتان را حل کنید! (در این باره Rubber Duck Debugging را هم نگاهی بیندازید! کوئرامگ هم مطلبی در همین زمینه دارد.)مرتب استراحت بدهید. کار دو نفره خیلی هیجان‌انگیز است، اما حسابی انرژی می‌گیرد. اگر دیدید انرژی‌تان تخلیه شده، نترسید؛ پیشنهاد استراحت بدهید. می‌شود در این فرصت در مورد آخرین جنجال مطرح در شبکه‌های اجتماعی حرف زد، قهوه دبشی خورد، با اعضای تیم گپ زد، یا اینکه صرفاً در هوای آزاد چند نفس عمیق کشید. مهم نیست در تایم استراحت چه کار کنید؛ فقط کافی است از پشت میز بلند شوید و تغییر مکان بدهید. نگران نباشید، ذهنتان قرار است در پشت پرده به تلاش برای حل مسئله‌ها ادامه بدهد؛ در نتیجه وقتی سر کار برمی‌گردید، با ایده‌های جدید و تازه‌ای وارد میدان خواهید شد.جفت‌ها را مرتب عوض کنید. با کار دو نفره، می‌توان دانش هر عضو تیم را بین کل اعضای تیم پخش کرد. از اطلاعات بخصوص در مورد سیستم گرفته تا مسائل تخصصی و بسیار فنی، آدم از هرکسی می‌تواند یک چیزی یاد بگیرد. (و البته از چالش‌های ضریب اتوبوس جلوگیری کند!) حتی فقط با تماشای نحوه مواجهه یک نفر دیگر با یک مشکل، فرمان‌های مورد استفاده او، یا حتی صرفاً رفتار و نگرش‌اش کلی ایده می‌شود گرفت. باورتان نمی‌شود که برنامه‌نویسی با آدم‌های مختلف، چند بار باعث شده با خودم فکر کنم که «وا، چطوری من تا الان از این خبر نداشتم؟!»تست‌های خودکار بنویسید. هیچ چیزی مثل یک مجموعه تست درست حسابی برای سنجش سیستم آدم را از کدهایش مطمئن نمی‌کند. وقتی دوتایی کار می‌کنید، هر دو باید در مورد نحوه تست کردن به توافق برسید. نظرات مختلفی در مورد نحوه انجام این کار هست؛ مثلاً تست کردن اول کار، تست کردن آخر کار، یا هر مدل دیگری که برای تیم شما جواب بدهد.جفت کردن پینگ‌پونگی را امتحان کنید. جفت کردن پینگ‌پونگی خیلی مفرح است و ریتم قشنگی هم به کار می‌دهد! چه طور انجامش بدهیم؟ یک نفر تست را می‌سازد، آن وقت آن یکی باید کاری کند که کدها از تست سربلند بیرون بیایند. حالا جاها عوض، و این چرخه ادامه دارد!خواب کافی داشته باشید. برنامه‌نویسی دونفره، مثل این است که آدم در عرض یک ساعت درس سه جلسه را یاد بگیرد. خواب، مکانیسم بدن ما برای هضم سیل اطلاعاتی است که داخل مغزمان می‌چپانیم. کافیست کمتر از اندازه بخوابیم تا تمرکز و توانایی تصمیم‌گیریمان پایین بیاید. این راه خوبی برای خوب برنامه‌نویسی کردن نیست. یکی از همکاران من که با هم برنامه نویسی دو نفره می‌کردیم، از فشار کار مرتب خواب می‌دید که یک Object است که هی دارد در سیستم اینور و آنور می‌شود.در برنامه نویسی دو نفره، خوش‌گذرانی را فراموش نکنید!خوش بگذرانید. کار دو نفره جلسه کاری نیست! لازم نیست جدی و با سگرمه‌های درهم آن را جلو ببریم. تا می‌توانید فرآیند برنامه‌نویسی‌تان را شبیه بازی کنید، جوک بگویید، کمی از آن همه جدیت کم کنید! این که چقدر می‌توانید در این روند خوش بگذارنید، به خلاقیت و ظرفیت شخص شما برای تفریح بستگی دارد!پژوهش‌ها نشان داده‌اند که خنده و شوخ‌طبعی به یادگیری کمک می‌کند؛ بخصوص اگر در مورد کاری باشد که دارید انجام می‌دهید. فقط حواستان باشد که از آنها به عنوان راهی برای فرار از کار استفاده نکنید!از تنوع استقبال کنید. هرکدام از ما، تاریخچه شخصی و منحصر بفرد خودش را دارد. هرچه اعضای یک تیم متنوع‌تر باشند، ایده‌های جالب بیشتری در مورد راهکار حل مشکلات خواهند داشت. از خاص بودن افراد لذت ببرید. تفاوت‌های میان آنها را جشن بگیرید. با این کار، بر سوگیری‌های درونی‌مان پیروز خواهیم شد.اگر با برنامه‌نویسی دو نفره یا کد جلوی رویتان تازه آشنا شده‌اید...کار هم‌تیمی‌تان را دنبال کنید و دیده‌هایتان را به ذهن بسپارید. تماشا کردن کد زدن یک نفر دیگر تجربه‌ استثنایی‌ای است؛ آدم کلی چیز یاد می‌گیرد. همه تلاشتان را بکنید تا عقب نمانید. شاید اول کار خیلی فشار بیاید و احساس کنید که همه چیز زیادی سریع پیش می‌رود، اما بعد ازچند روز کم‌کم از همه چیز سردرخواهید آورد. به مرور، اول الگوهای کوچک را شکار می‌کنید؛ مثلا «آهان، پس اینجوری تست هارو اجرا می‌کنم» یا «اینطوری اپلیکیشن Launch میشه». بعد از آن کم‌کم جا در ذهنتان برای تمرکز روی مفاهیم پیچیده‌تر باز می‌شود.اگر سردرگم شدید، به همکارتان بگویید. آن اوایل کار، خیلی وقت‌ها ممکن است آدم حسابی گیج و سردرگم شود. موقعیت ترسناکی است، اما یادتان باشد که چنین واکنشی کاملاً طبیعی است. اگر همکار خوبی داشته باشید، احتمالاً حواس‌ش هست که در چنین مواقعی ترمز بزند و کمی سرعت را کم کند. یکی از اجزای لازم برای برنامه‌نویسی خوب دو نفره، داشتن ارتباطی صادقانه است. اگر صادقانه همکارتان را از وضعیتتان مطلع کنید، در کنار هم مسیر پیش رو را درست خواهید کرد و هر مشکلی که پیش آمد، می‌توانید با آن روبرو شوید.سوال بپرسید. چرا این کارو کردی؟ چی تو فکرته؟ چطوری فهمیدی که از اینجا باید شروع کنی؟ ببینید چه برایتان مبهم و نامشخص است، و بعد در موردشان سوال بپرسید. اما به این هم دقت کنید که سوال‌پیچ کردن همکارتان ممکن است فرآیند فکر کردن او را مختل کرده و سرعتش را پایین بیاورد. اگر سوال‌هایتان خیلی زیاد است، می‌توانید یک صفحه کاغذ کنارتان بگذارید و آنها را بنویسید تا از یادتان نروند.بیشتر از بیشتر بخوابید. جدی می‌گویم!حواستان به ددلاین‌ها باشد. در یک دنیای ایده‌آل، همکارتان سرعتش را در حد شما پایین می‌آورد و به شما اجازه می‌دهد تا به مرور سرعت خودتان را زیاد کنید. اما متاسفانه دنیای واقعی آنقدر‌ها هم ایده‌آل نیست. اضافه کردن یک عضو جدید به تیم به بهره‌وری تیم صدمه می‌زند، حتی اگر یک نیروی کارکشته و Senior باشد. باید سعی کرد تا بین کاهش بهره‌وری و لزوم تحویل کار، تعادل برقرار شود. بپذیرید که همکارتان هم مثل همه آدم‌ها با ایده‌آل فاصله دارد، و ممکن است با نزدیک شدن ددلاین‌ها مضطرب یا بی‌صبر شود.نکاتی برای کارکشته‌های برنامه نویسی دو نفرهسطح برنامه‌نویسی دوتایی‌تان را یک مرحله بالاتر ببرید. با کمی فکر و اندکی ابتکار، همیشه می‌شود راهی برای بالاتر بردن سطح برنامه‌نویسی دونفره پیدا کرد. من ماه‌ها و ماه‌ها روی یک پروژه دونفره با یک نفر ثابت کار می‌کردم. به شکل احمقانه‌ای، هیچ‌کدام از ما هیچوقت به ذهنمان خطور نکرد که با جفت دیگری که درست کنارمان نشسته بودند، یار عوض کنیم. مسخره است‌! هردو تیم در این سناریو باخته‌اند.هیجاناتتان را مدیریت کنید. در هر روز از برنامه‌نویسی دو نفره، شما با ترس‌ها و ضعف‌های خودتان روبرو خواهید شد: تکبر، ترس از احمق به نظر آمدن، سر رفتن حوصله. این ضعف‌ها را انکار نکنید. در عوض، آنها را به رسمیت بشناسید و ببینید چه استراتژی‌ای برای کم کردنشان می‌شود پیدا کرد. این چالشی است که در تمام زندگی‌تان ادامه خواهد داشت. ویژگی‌هایی که به همکار خوب بودن در برنامه نویسی دونفره کمک می‌کنند عبارتند از صبوری، احترام، تحمل، فروتنی، شجاعت، و صداقت.به مدل فکر کردن آدم‌ها دقت کنید. وقتی کل عمرت را با یک مغز زندگی کرده‌ باشی، به راحتی از یاد می‌بری که مغز بقیه آدم‌ها جور دیگری کار می‌کند. نه تنها بقیه با شما فرق دارند، که نحوه تفکر و پردازش ذهن هرکدام از آنها هم منحصر به فرد است. به سبک تفکر همکارتان دقت کنید؛ آیا وقت‌هایی که عمیقاً در فکر است و چیزی نمانده به راه حل برسد، شما هی حرف می‌زنید و مانعش می‌شوید؟ آیا همکارتان نیاز دارد که با سرعت کمتر (یا بیشتری) جلو بروید؟ آیا اگر با مثال حرفتان را توضیح بدهید، بهتر متوجه می‌شود؟ هرچقدر همکارهایتان را بهتر درک کنید، کار تیمی موفق‌‌تری با او خواهید داشت. آن وقت، هر دویتان رشد خواهید کرد.روی خودآگاهی‌تان کار کنید. درست همانطور که بهتر فهمیدن همکارتان باعث پیشرفت می‌شود، دانستن این که خودتان چه جور آدمی هستید و به چه نیاز دارید هم شما را رشد می‌دهد. وقتی نیازهایتان را بهتر بشناسید، بیشتر ممکن است که آنها را برآورده کنید.از زبان با دقت استفاده کنید. تفاوت بفرما و بتمرگ را که شنیده‌اید؟ در برنامه‌نویسی دونفره هم مثل همه جاها، به نحوه حرف زدن خود دقت کنید و مچ خودتان را وقت گفتن جملات قضاوت‌بار بگیرید. به عنوان مثال وقتی کسی می‌گوید که «پس چرا کار X رو نکردی؟» در واقع دارد زیرپوستی القا می‌کند که «پسر، تو واقعاً احمقی!». به جای این عبارت قضاوت‌بار، می‌توانید از این عبارت‌ها استفاده کنید:راستی به کار ایکس هم فکر کردی؟یه مشکلی که این کار داره می‌تونه این باشه که...دارم فکر می‌کنم که این کار جواب میده یا نه...به نظرت اگه کار X رو بکنیم چه اتفاقی می‌افته؟· اوکی هستی که کار X رو هم امتحان کنیم؟موفقیت کل تیم مهم‌تر از موفقیت فردی است.سرعت شخصی (Local) در مقابل سرعت جمعی (Global). خیلی‌ وقت‌ها افراد به اشتباه فکر می‌کنند که به نفع تیم است اگر خودشان تا جایی که می‌توانند سریع کار کنند (سرعت شخصی). این درست نیست! هدف ما باید این باشد که اعضای تیم به شکل دسته‌جمعی بتوانند بیشترین ارزش را با بیشترین سرعت ممکن ایجاد کنند (سرعت جمعی). افراد به شکل‌های مختلفی در دام تفکر مبتنی بر سرعت شخصی می‌افتند. مثلاً وقتشان را روی کارهای اشتباهی می‌گذارند، به تعمیر کردن یک Build خراب کمک نمی‌کنند، و برای جواب دادن به سوال مهمی که یکی دیگر از اعضای تیم مطرح کرده، وقت اختصاص نمی‌دهند.حرف‌های سخت را رک و راست بگویید. برنامه‌نویسی دونفره کمی شبیه ازدواج است: باید با هم کنار آمد، اما صادق هم بود. همکارتان بوی عرق می دهد؟ نفسش بدبو است؟ سر کیبورد غذا می‌خورد؟ خب، همه ما بعضاً ممکن است روز بدی را گذارنده باشیم و خیلی حوصله نداشته باشیم به خودمان برسیم. اما اگر این جور چیزها مرتباً تکرار می‌شوند و روی اعصاب شما هستند، خوب است مطرحشان کنید. این کار جرات می‌خواهد، اما با گفتنشان در درازمدت هم به خودتان لطف کرده‌اید و هم به همکارتان. بعضی وقت‌ها، صرف مطرح کردنش هم باعث می‌شود آدم حس بهتری پیدا کند.قوانین را دور بزنید. دو نفره کار کردن هنر است، درست مثل برنامه نویسی. قوانین کمی هستند که نشود تغییرشان داد. آزاد اندیش باشید و از امتحان کردن چیزهای جدید استقبال کنید. به نتایج این امتحان کردن‌ها دقت کنید و اگر می‌توانید آنها را اندازه بگیرید. هرچیزی که جواب می‌داد، باز هم تکرارش کنید.ترجمه بر اساس: "Pair Programming: A (Semi-) Definitive Guide" by Rob Isenberg @ Hackernoonکوئرامگ مجله‌ی تخصصی کوئرا برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید توئیتر یا کانال تلگرام ما را دنبال کنید. مریم مقدس برهان مریم مقدس برهان Mon, 19 Aug 2019 13:41:57 +0430 https://virgool.io/Quera-Mag/%DA%86%D8%B1%D8%A7-%D9%81%D8%B1%DB%8C%D9%84%D9%86%D8%B3%D8%B1%DB%8C-%D8%A2%D9%86%D8%B7%D9%88%D8%B1-%DA%A9%D9%87-%D9%87%D9%85%D9%87-%D9%81%DA%A9%D8%B1-%D9%85%DB%8C%DA%A9%D9%86%D9%86%D8%AF-%D8%B1%D9%88%DB%8C%D8%A7%DB%8C%DB%8C-%D9%86%DB%8C%D8%B3%D8%AA-qoyqipt0yqxy تسا پالمر، مدیوم -- دارید به ورود به دنیای فریلنسری فکر می‌کنید؟ صبر کنید! قبل از اینکه در رویای شیرین کار کردن با پیژامه در رختخواب غرق شوید، چیزهایی هست که باید در موردشان بدانید. من یک فریلنسرم و می‌‌خواهم برایتان بگویم که چرا این نوع زندگی آنقدرها که فکر می‌کنید هم هیجان‌انگیز نیست.- ولی از کارمندی که بهتره، مگه نه؟معلومه که آره! اما هیچ نوع کاری ایده‌آل نیست، حتی فریلنسری. اگر با آن چشمان گرد و براقی که شخصیت‌های ذوق‌زده توی انیمه‌ها دارند وارد این وادی شوید، قرار است حسابی توی ذوقتان بخورد. در این پست، من می‌خواهم صادقانه و طبق تجربیات خودم از ایرادهای فریلنسری برایتان بگویم تا اگر فکر فریلنسر شدن به سرتان زده، بتوانید با چشم باز و انتظاراتی واقع‌گرایانه تصمیم بگیرید.۱۰ بخش ناخوشایند فریلنسری۱. تنهایی، تنهایی عریانبرای اغلب ما فریلنسرها، فریلنسری یعنی کار کردن در خانه. اما وقتی ساعت‌ها و روزها و هفته‌ها در خانه تنها بمانید، جای تعاملات رودررویی که با همکارانتان در شرکت داشتید بدجور حساس می‌شود. فقط یک لحظه تصورکنید که ساعت‌ها جز صفحه مانیتور هیچ‌کس را برای حرف زدن نداشته باشید. بله، دیگر کسی نمی‌تواند اپیزود بعدی گیم‌آوترونز را برایتان اسپویل کند، اما کسی هم نیست که وقتی این اپیزود را دیدید با او در موردش حرف بزنید.چه آدم درونگرایی باشید و چه برونگرا، دیر یا زود بلاخره یک جایی حس تنهایی گیرتان می‌اندازد. برای همین است که به نظر شخصی من، تعامل داشتن با جامعه برای فریلنسرها خیلی خیلی ضروری‌تر از افراد دیگر است. یعنی چی؟ یعنی اگر فریلنسر شدید باید برای روابط غیر کاری خود با دیگران خیلی بیشتر از قبل مایه بگذارید. حالا چه با داوطلب شدن در یک سازمان مردم‌نهاد، چه با شرکت در رویدادهای اجتماعی، و چه با بیشتر گشتن با دوستان.همچنین سعی کنید تا می‌شود، با مشتری‌ها هم به جای چت کردن تلفنی صحبت کنید. اگر کارمند بودید، این تعامل قرار بود با برگزاری جلسه شکل بگیرد، اما با تلفن زدن می‌شود تا حدی آن را جبران کرد. یک راهکار دیگر هم این است که هر از گاهی برای قهوه از خانه بیرون بزنید. به این ترتیب می‌توانید یک استراحت درست و حسابی داشته باشید که در آن از محیط کارتان دور هستید.۲. در هم پیچیدن زندگی‌ شخصی و زندگی کاریاغلب فریلنسرها، بخصوص آنها که تازه وارد این وادی شده‌اند، با یک لپتاب یکسان، هم ایمیل‌های کاری‌ جواب می‌دهند و هم توییتر چک می‌کنند. این کار دو ایراد دارد: از یک طرف تعداد عوامل حواس‌پرت‌کن زیادتر می‌شود، از آن طرف ممکن است رها کردن کار و استراحت کردن برای آدم خیلی سخت بشود.من موبایلم را هم برای کار استفاده می‌کنم و هم برای تماس‌های شخصی. کامپیوترم را هم همینطور. اتاقی که بخش اعظم کارم را در آن جلو می‌برم همان اتاقی است که در آن صبحانه می‌خورم. این یعنی مشتری‌ها می‌توانند هر ساعت شبانه‌روز که عشقشان کشید با من تماس بگیرند.بعضی وقت‌ها حتی بعد از اینکه روز کاری تمام شد هم عذاب وجدان ناشی از کار نکردن یقه‌ آدم را ول نمی‌کند. چرا؟ چون هیچ تغییری در محیط صورت نگرفته، و همان دستگاه‌های الکترونیکی که با آنها کار می‌کردید هنوز هم جلوی شما هستند.۳. یعنی می‌تونم از این هم پول دربیارم؟اگر فریلنسر هستید، خودتان را عادت بدهید که همه چیز را به چشم پول نبینید!وقتی آدم متوجه می‌شود که می‌تواند مهارت‌هایش را به همین سادگی بفروشد، یک اتفاق عجیب در ذهنش می‌افتد. تام و جری را یادتان هست که هروقت تام گرسنه می‌شد، جری را شکل ران مرغ می‌دید؟ ما فریلنسرها هم کم‌کم هر فعالیت ممکنی را به شکل یک کار پول‌درآر می‌بینیم! این عادت جدیدی است که من در مورد تفریح‌هایم پیدا کرده‌ام. عکاسی یکی از تفریحات لذت‌بخش من است. بارها و بارها با خودم فکر کرده‌ام «به به چه عکس‌های قشنگی انداختم! یعنی میتونم بفروشمشون؟». اما خوشبختانه، گوش شیطان کر، هنوز قدمی در این راستا برنداشته‌ام.به نظر من تبدیل کردن تفریح‌ها به فرصت پول درآوردن، کار خطرناکی است. راحت می‌شود گیر این وسوسه‌ها افتاد، اما نباید از یاد ببریم که کار همه چیز نیست. آدم باید فعالیت‌هایی هم داشته باشد که بتواند در آنها فشارهای کاری را کنار بگذارد و فقط لذت ببرد. اگر اینطور نباشد، کل زندگی‌مان حول محور پول خواهد چرخید.۴. در به در، به دنبال جستجوی مشتریبرخلاف کار شرکتی که همیشه یکی دیگر مسئول سر و کله زدن با مشتری است، در فریلنسری مشتری پیدا کردن خیلی دردسر دارد. نه تنها کل کار جذب مشتری با خود شماست، که مشتری‌ها ممکن است هر لحظه که دلشان خواست همکاری‌شان با شما را قطع کنند!راهکارش چیست؟ با کمی صبر و کمی تجربه، آدم یاد می‌گیرد قبل از بستن قرارداد مشتری خوب را از بد تشخیص بدهد. اما این مهارتی است که زمان می‌برد و باید برایش زحمت کشید.حتی اگر مشتری‌های خوبی شکار کنید، ممکن است بعد از یک پروژه کار را کنسل کنند. اما اگر خودتان را در چشم مشتریان ارزشمند جلوه بدهید، آنها مرتب به آغوشتان باز خواهند گشت.۵. خودم رئیس خودمم؟ عمراً!قبل از اینکه با حس پرنده‌ای آزاد در آسمان آبی کارمندی را برای همیشه کنار بگذارید، اجازه بدهید یک حقیقت تلخ را با شما درمیان بگذارم: فریلنسر هم که بشوید باز هم قرار است برای یک نفر دیگر کار کنید!برای حل این مشکل، من در تلاشم تا در عین اینکه مشتری‌های متنوع کار پاره‌وقت می‌کنم، کسب و کار خودم را هم راه بیندازم. از ایده ترکیب کردن فریلنسری و کارآفرینی خیلی خوشم می‌آید، فکر می‌کنم خیلی خوب می‌توانند همدیگر را تکمیل کنند! حداقل تا اینجا که ترکیبشان برای من جواب داده.۶. باز که دوازده شب شد...بعضی‌وقت‌ها برای تحت تاثیر قرار دادن مشتری‌ها (بخصوص آنهایی که تازه مشتری‌ام شده‌اند)، کمی بیشتر از معمول برایشان انرژی می‌گذارم؛ مثلاً تا خود نصف شب بکوب کار می‌کنم تا پروژه را سریع تحویل بدهم، یا اینکه با وجود تمام شدن ساعت کاری‌ام می‌نشینم و کلی برای پیدا کردن راه حل یک مسئله مربوط به پروژه، ایده می‌زنم. همه می‌گویند فریلنسرها ساعات کاری‌شان منعطف است، اما بعضی وقت‌ها همین انعطاف به جای اینکه حس آزادی بدهد، بدتر آدم را در قفس می‌اندازد.بعضی وقت‌ها هم ممکن است مثل من، مشتری‌هایی داشته باشید که آن سوی دنیا و در منطقه‌های زمانی کاملاً متفاوت زندگی می‌کنند. کار کردن با این مشتری‌ها درآمد خوبی دارد، اما در عین حال برابر است با سردردهای فراوان و بی‌خوابی‌های پشت سر هم.راهکار من برای به دست گرفتن کنترل ساعات کاری‌ام، صریح بودن با مشتری است. برایشان به وضوح مشخص کنید که چه زمان‌هایی از روز و چه روزهایی از هفته در دسترس خواهید بود و چه زمان‌هایی نه. اگر قرار است چند روزی استراحت کنید، به آنها هم اطلاع دهید که تا فلان زمان سر کار نخواهید بود.۷. کار نکردن = حقوق نگرفتنمرخصی رفتن برای فریلنسرها یعنی تعطیل شدن درآمدیکی از بخش‌های جذاب کارمندی برای من، این بود که می‌توانستم مرخصی‌ام را کنار ساحل و به تماشای آب‌های مواج بگذرانم، آن وقت حقوقم همچنان بدون این که ذره‌ای کار کرده باشم به حسابم واریز شود! فریلنسرها از این مزیت بی‌بهره‌اند. هر ساعت مرخصی، یعنی از دست دادن حقوق یک ساعت کار.۸. درآمد فریلنسری مقایس‌پذیر نیست!بعضی‌ شغل‌ها مقیاس‌پذیرند؛ یعنی شما می‌توانید بدون اینکه میزان تلاش خود را بیشتر کنید، درآمد بیشتری از آنها داشته باشید؛ مثلا گرفتن سهام، فروش یک کتاب خوب، بازی در یک فیلم پرفروش. اما فریلنسری جزو شغل‌های مقیاس‌پذیر نیست. شما بر مبنای تعداد ساعات کاری که می‌کنید پول می‌گیرید. حتی اگر دستمزد ساعتی‌تان را بالا ببرید، در نهایت تعداد ساعات محدودی در هفته می‌توانید کار کنید. دستمزد شما هرگز از جمع تعداد ساعات هفته X دستمزد بالاتر نخواهید رفت.اگر با این قضیه اوکی‌اید، که خب خیلی عالی! اما اگر کار غیرمقیاس‌پذیر با شما نمی‌سازد، شاید بهتر باشد به درآمدهای منفعلانه تر فکر کنید و یا اینکه کسب و کار خودتان را راه بیندازید.۹. خودت روی پای خودت وایستامتاسفانه برای فریلنسرها هیچ خط تلفنی برای دریافت پشتیبانی فنی یا تماس با مدیریت منابع انسانی وجود ندارد. اگر سیستم پرداختتان به مشکل خورد یا اینترنت قطع شد، شمایید که باید مشکل را حل کنید. اگر در رابطه با مشتری به اختلاف خوردید، خودتان باید ناز مشتری را بخرید. اگر لپتابتان آسیب دید، پول تعمیرش را شما باید بدهید.۱۰. اممم...چطوری بگم...بعضی صحبت‌های ناخوشایند هستند که همه‌ ما باید با کارفرماهایمان داشته باشیم: چانه زدن در مورد دستمزد، گفتگو در مورد خزش محدوده (Scope creep)، و مصاحبه استخدامی. اگر فریلنسر شوید این صحبت‌ها را نه فقط با یک کارفرما، که با تک تک مشتریان باید داشته باشید!اما خبر خوب این است که عذاب این گفتگوها به مرور زمان کم می‌شود. کم کم یاد می‌گیرید که چطور صحبت‌های سخت را ماهرانه جلو ببرید، و یا حتی کاری کنید که کلا از بیخ‌وبن نیازی به این صحبت‌ها نباشد.ترساندمتان!؟امیدوارم اینطور نباشد! هدف من فراری دادن شما از فریلنسری نیست. من عاشق فریلنسری‌ام و به همه هم پیشنهاد می‌کنم امتحانش کنند!اما امیدوارم که حالا انتظارات واقع‌بینانه‌تری در مورد آن داشته باشید. فریلنسری بی‌نظیر است، اما مطالب کمی هستند که درباره بخش‌های بد آن حرف زده باشند. من می‌خواستم بر مبنای تجربه‌هایم کمی شما را قبل از ورود به این وادی راهنمایی کنم.اگر به فریلنسری فکر می‌کنید، حدس می‌زنید کدام‌یک از این مشکلات بیشتر اذیتتان کنند؟ اگر قبلا فریلنسری را تجربه کرده‌اید، آیا همانطوری بود که انتظارش را داشتید؟ تجربه‌هایتان را با ما در میان بگذارید!ترجمه بر اساس:"10 Honest Reasons Why Freelancing Sucks (And My Thoughts on How to Deal With Them)" by Tessa Palmer @ Mediumکوئرامگ مجله‌ای تخصصی برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید توئیتر یا کانال تلگرام ما را دنبال کنید. مریم مقدس برهان مریم مقدس برهان Tue, 06 Aug 2019 16:47:35 +0430 https://virgool.io/Quera-Mag/%D8%AD%D8%A7%D9%81%D8%B8%D9%87-%D8%B1%D8%B4%D8%AF-%D9%81%D8%B1%D8%AF%DB%8C-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3-e64f7p51dm3x جفری شِک، سنریگن — کار کردن مرا از پا انداخته بود. مهندس نرم‌افزاری بودم که سه سال بود در شغلش درجا می‌زد. حافظه‌ام در افتضاح بودن همتا نداشت. نمی‌دانم که حافظه‌ام به خاطر استرس اینقدر خراب بود، کمبود خواب داشتم، یا اینکه همیشه همینطور بد بوده و من خبر نداشتم. کار برایم تبدیل شده بود به چرخه‌ای از «امروز دیگه قراره تغییر کنم»ها که به ردیت‌گردی، مدیوم‌خوانی و هکرنیوزبازی‌ با طعم بیزاری از خود ختم می‌شدند. سعی می‌کردم با این گشت و گذارها، دوپامینی که سر کار به دست نمی‌آوردم را جبران کنم؛ اما یک آدم شکست‌خورده بیش نبودم.من دلم می‌خواست مهندس نرم‌افزار خوبی باشم؛ خوب نه، می‌خواستم شاهکار باشم! اما فقط متوسط بودم. بدترین بخش قضیه متوسط بودنم نبود، این بود که داشتم همه زورم را می‌زدم تا خوب باشم! شش روز هفته هر روز دوازده ساعت روی آن صندلی می‌نشستم و خودم را می‌کشتم که کد‌های خارق‌العاده پایتون بزنم؛ اما مرتب مجبور بودم مستند‌سازی‌ها را چک کنم و مدام در چاله حواس‌پرتی‌های اینترنتی گیر می‌افتادم. آدم شکست خورده‌ای بودم، اما یک شکست‌خورده‌‌ کوشا.آنوقت روبروی من همکارم کایل نشسته بود؛ کایلی که همزمان با من و مثل من برنامه‌نویسی را از صفر شروع کرد، مثل من سر کار آن را یاد ‌گرفت. اما بعد از سه سال تلاش وقتی من هنوز داشتم تاتی‌تاتی‌کنان زمین می‌خوردم، او نه تنها می‌دوید، که بال هم درآورده بود و پرواز می‌کرد.آرزویم بود که همه شرکت‌های فناوری مرا بخواهند، که ده برابر پربازده‌تر از یک مهندس نرمال باشم! یعنی همان چیزی که اهالی سیلیکون ولی به آن می‌گویند «مهندس ده برابری» (10X Engineer).در عوض داشتم درجا می‌زدم. آنوقت تک به تک همکارانی که سابقه بالای پانزده سال داشتند وِرد زبانشان این بود: «وای، کایل اولین مهندس ده‌برابریه که تو عمرم دیدم!»کایل فقط در روزهای هفته کار می‌کرد، از ساعت ۱۰ صبح تا ۴ عصر. همیشه کارش را زودتر از موعد تمام کرده بود. خودش به تنهایی باعث و بانی ۸۰٪ از خروجی تیم بود. اما چیزی که بیشتر از همه نمک روی زخم من می‌پاشید، این بود که کایل فقط ۶۰٪ مواقع داشت کار می‌کرد! اگر گفتید بقیه وقتش صرف چه می‌شد؟ بله، هکرنیوز، ردیت و مدیوم! من آن حلزونی بودم که دو سانت از دیوار بالا می‌رفت و یک سانت سقوط می‌کرد، آن وقت کایل خرگوش رشید و رعنایی بود که با یک جهش از روی دیوار می‌پرید.کایل حتی یکی از عادت‌های موثر مردمان موفق را هم نداشت. هیچوقت مدیتیشن نمی‌کرد. صبح و ظهر و شب مک‌دونالدز می‌خورد، اما پوست و استخوان بود. در عوض یک توانایی ابرقهرمانی داشت: یک حافظه تصویری بی‌نظیر در سینتکسِ API و مستندسازی!من هم دلم می‌خواست حافظه خوب داشته باشم. حسودی‌ام می‌شد. مدت‌ها بود که یک ذره هم پیشرفت شغلی نکرده‌ بودم، و دیگر وقتش بود که یک چیزی تغییر کند. اینجا بود که سفر طولانی و متعهدانه‌ام را در وادی تکرار فاصله دار (Spaced Repetition) آغاز کردم. برای مدت سه سال هر روز، یک تا سه ساعت روی تکرار فاصله‌دار وقت گذاشتم. سفری سخت بود و بی‌رحمانه، اما لازمش داشتم.تکرار فاصله دار چیست؟ تکرار فاصله‌دار تکنیکی برای یادآوری است. در این تکنیک، شما مفاهیم را در فواصل بخصوص یادتان می‌آورید و به این ترتیب، میزان نگهداری آن اطلاعات در حافظه را به بهینه‌ترین حالت می‌رسانید. تکرار فاصله‌دار استراتژی‌ای برای یادآوری اطلاعات به مغز است. این تکنیک می‌گوید که بهترین زمان برای به یادآوردن یک نکته، درست همان وقتی است که تازه شروع به فراموش کردن آن می‌کنیم. ذهن‌ ما فراموش‌کار است، اما می‌توانیم با به کار بستن یک استراتژی‌ مناسب، کمی از فراموش‌کاری‌اش کم کنیم. منحی ثبت اطلاعات در حافظه و فراموشی آن‌هاوقتی فواصل بین دفعات یادآوری رفته رفته زیاد می‌شوند، احتمال وارد شدن اطلاعات به حافظه طولانی‌مدت بیشتر می‌شود و احتمال فراموش کردن آنها، کمتر. به شکل بالا دقت کنید؛ می‌بینید چطور وقفه‌ی قبل از هر یادآوری، از وقفه‌ی یادآوری قبل خودش طولانی‌تر شده؟نکته: این تصویر هم دقیقاً همان حرفی را می‌زند که تصویر بالایی می‌گفت، اما چون رنگش متفاوت است باعث می‌شود بیشتر در حافظه باقی بماند. دیدید؟ من سرشار از نکته‌های مفیدم!بیایید فرض کنیم که شما در طول یک سال، شش بار فرصت دارید تا اسم خودتان را به بیل گیتس یادآوری کنید. اگر بیل بعد از یک سال اسم شما را یادش ماند، یک میلیون دلار به شما جایزه می‌دهد!کدام روزها را برای یادآوری اسمتان به او انتخاب می‌کنید؟مدل ۱، مدل درس خواندن شب امتحانی: ۲۴ اسفند، ۲۵ اسفند، ۲۶ اسفند، ۲۷ اسفند، ۲۸ اسفند، ۲۹ اسفندمدل ۲، مدل دانش‌آموز نمونه: روز اول ماه با فاصله‌های ۲ ماهه! در اول فروردین، اول خرداد، اول مرداد، الی آخر.مدل ۳، مدل تکرار فاصله‌دار: اول فروردین، سوم فروردین، ۲۰ فروردین، ۲۸ اردیبهشت، ۱۵تیر، ۳۰ آذر.با گزینه سوم (تکرار فاصله‌دار) بیشترین شانس را برای ثبت کردن اسمتان در ذهن بیل گیتس خواهید داشت! (چقدر ما نویسنده‌هایی که حرف‌های بدیهی می‌زنیم روی اعصابیم، نه!؟)اما چرا گزینه ۳ بهترین ثبت در حافظه را دارد؟مدل ۱. درس خواندن شب امتحانی به ندرت جواب می‌دهد؛ زیرا اطلاعات به محض اینکه از حافظه کوتاه‌مدت درآمدند، روانه سطل آشغال می‌شوند. چند تا از درس‌های مدرسه که شب امتحان برایشان خواندید را الان یادتان مانده؟مدل ۲. یادآوری در فواصل زمانی منظم نسبتاً جواب می‌دهد، اما باید در هر بار یادآوری همه دانشتان را از نو مرور کنید. این کار نه ممکن است، نه خوش می‌گذرد، و نه اینکه کار و زندگی برای آدم می‌گذارد.مدل ۳. مغز ما با یادآوری در فواصل نمایی از همه بهتر کار می‌کند. جز در اپلیکیشن‌های زبان‌آموزی (مثل Duolingo) و بین دانشجویان پزشکی، تکنیک تکرار فاصله‌دار چندان رایج نیست. ولی حتی اگر به اندازه درس خواندن شب امتحانی کار خفنی نباشد، حداقل نتیجه می‌دهد. دانشجویان پزشکی با کمک این تکنیک است که کتاب‌درسی‌های هزار صفحه‌ای را یادشان نگه می‌دارند. اگر Duolingo از تکرار فاصله‌دار استفاده می‌کند، برای این است که از آن جواب می‌گیرد. برندگان این مسابقه‌های حافظه را دیده‌اید؟ خیلی‌هاشان طرفدار پر و پا قرص تکرار فاصله‌دارند. خب اگر تکرار فاصله‌دار اینقدر شگفت‌انگیز است، پس چرا آدم‌های کمی از آن استفاده می‌کنند؟چون مردم از وجود چنین تکنیکی خبر ندارند.چون حتی اگر این تکنیک را به کار ببرید، عادت دادن خودتان به مرور روزانه فلش‌کارت‌ها کار سختی است.چون فلش‌کارت درست کردن کار رو اعصابی است. چه کسی خوشش می‌آید مدت‌ها بنشیند و داخل یک اپلیکیشن یادداشت تایپ کند؟چون مردم خیلی دوست دارند در مورد بهتر کردن خود حرف بزنند، اما دلشان نمی‌خواهد بخش عرق‌درآر کار را انجام بدهند.چون خیلی کار پرستیژداری نیست. اگر بخواهید با یک دختر/پسر رعنا سر قرار بروید، خیلی دوست نخواهید داشت که از عادت فلش‌کارت خواندنتان برایش تعریف کنید.اما مهندسین نرم‌افزار هیچ‌کدام این مشکل‌ها را ندارند...شاید بی‌خبری از تکنیک تکرار فاصله‌دار برای خیلی‌ها ضرری نداشته باشد، اما از مهندس‌ها انتظار می‌رود از ترندهای روز خبر داشته باشند. اگر اینطور نبود، هنوز داشتیم BitBucket و Adobe Flash استفاده می‌کردیم.مهندس‌ها آدم‌های عادت‌دوستی‌اند و راحت می‌توانند عادت مرور فلش‌کارت را در خود ایجاد کنند. می‌توانید همیشه در یک زمان بخصوص فلش‌کارت‌ها را مرور کنید تا عادت شود؛ مثلاً به محض این که به شرکت رسیدید و سر میز نشستید، وقتی سوار مترو شدید، یا حتی در دستشویی درست قبل از رفتن به سراغ کندی‌کراش. وقتش شده که از پنجاه بار سرچ کردن «چطور کامیت گیت خود را اصلاح کنیم» در StackOverFlow دست بردارید!فلش کارت ساختن برای ما آنقدر هم سخت نیست؛ فقط کافی است به جای یادداشت کردن در Quiver، EverNote، Notion و غیره، یادداشتتان را در قالب فلش کارت ذخیره کنید.حتی اگر بهتر کردن خود کار عرق‌درآری باشد، از قدیم گفته‌اند برای اینکه مهندس نرم‌افزار خوبی باشی ز گهواره تا گور دانش بجوی.بیایید با هم رو راست باشیم؛ ما که با هیچ دختر/پسر رعنایی قرار نداریم!پراستفاده‌ترین اپلیکیشن‌ها برای تکرار فاصله‌دار، انکی (Anki) و سوپرممو (SuperMemo) هستند. با هردو این برنامه‌ها می‌شود فلش‌کارت درست کرد و بعد طبق یک الگوریتم فاصله‌دار، خود را آزمود. اگر سوال را اشتباه جواب دهید، برنامه همین فردا دوباره آن را از شما می‌پرسد. اگر درست جواب دهید، آن را به یک مدت بعدتر موکول می‌کند. من از انکی استفاده می‌کنم. به نظر می‌رسد که بین مهندسین نرم‌افزار، انکی رایج‌تر است. اپ موبایلش را دانلود کنید، هم آیفون دارد هم اندروید. اپ اندرویدش شاهکار است.یادآوری چند اصطلاح (برای اینکه مبادا فراموش کنید):تکرار فاصله‌دار، تکنیکی برای یادگیری است.اپلیکیشن‌های انکی و سوپرمِمو از تکرار فاصله‌دار استفاده می‌کنند. در انکی و سوپرممو، شما فلش‌کارت درست می‌کنید. بعد این اپلیکیشن‌ها از شما در فواصل مختلف آزمون می‌گیرند.به کل مجموعه فلش‌کارت‌های شما، Deck گفته می‌شود.من خودم را عادت داده‌ام که هروقت چیزی در StackOverflow سرچ کردم، بلافاصله سوال و جواب/جواب‌های آن را در انکی فلش‌کارت کنم.مثال: نمونه فلش کارت انکی - پارامتری برای gsutilاین یکی هم سوال ساده‌ای است که دیروز اشتباه جواب دادم. راستش را بخواهید، کمی خجالت می‌کشیدم به شما نشانش بدهم.تکرار فاصله‌دار، مثل یک StackOverflow دم‌دستی و آفلاین است. (بله، قبلا Dash را امتحان کرده‌ام!) در دوران پیشا-انکی، من مدام معادل سینتکسی آموخته‌های روزانه‌ام را فراموش می‌کردم. درست است که همان زمان هم با انکی اطلاعات عمومی حفظ می‌کردم، اما هیچوقت فلش‌کارت‌ برنامه‌نویسی درست نکرده بودم. چرا؟ به این دلیل:تنبلی. درست کردن فلش‌کارت برنامه‌نویسی خوب در انکی بعضا کار سختی است.به یاد سپردن فلش‌کارتی که داخلش کد دارد هم خیلی کار راحتی نیست. حفظ کردن پایتخت مغولستان (اولان‌باتور) ساده‌تر است تا حفظ کردن نحوه کپی کردن لیست فایل‌های درایو خارجی به فایل txt با استفاده از xargs (جواب: cat list.txt | xargs -l{} mv /Volumes/External/{} /Desktop). خیلی اعصاب‌خردکن است که یک کارت سخت را چند روز متوالی اشتباه جواب بدهی.ولی در سه سال گذشته، من همه چیز را وارد انکی کرده‌ام. Aliasهای بش، میانبرهای IDE، APIهای برنامه‌نویسی، مستندسازی، الگوهای طراحی، و غیره. با اینحال، به شما پیشنهاد نمی‌کنم که هر چیزی را به انکی اضافه کنید. فهرست اشتباهات من در انکی خودش یک پست جداگانه می‌طلبد...مزایای استفاده از Anki برای تقویت حافظهاز وقتی به آغوش Anki پناه برده‌ام و یادآوری سریع زبان و APIهای فریم‌ورک برایم مثل آب خوردن شده است، خدایان تمرکز و بازدهی بالاخره جواب دعاهای بی‌پایانم را داده‌اند! سه سال قبل، روند کار من (که شاید برای شما هم آشنا باشد) اینطوری بود: شروع کد زدنگشتن در StackOverflow به دنبال سینتکسی که یادم رفتهحواس‌پرتی. گشت وگذار در هکرنیوز.خب، هکرنیوز که هیچی نداشت. برویم سراغ ردیت؟ تلاش برای تمرکز روی کارناامیدی. بروم ببینم کسی مطلب جدیدی در هکرنیوز گذاشته؟با مجهز شدن به حافظه خوب در سینتکس API، مستندسازی، و پایتخت کشورها، روند کارم ازین رو به آن رو شده است. این گراف فلش‌کارت‌هایی است که من در سال ۲۰۱۶ مرور کرده‌ام؛ سالی پر از مرورهای کوتاه در وسط انبوهی از حواس‌پرتی‌های طولانی:گراف فلش‌کارت های مرور‌شده در انکی برای نویسندهو این یکی گراف امسال تا زمان نوشته شدن این متن است. انگار کم کم باید سرگرمی جدیدی پیدا کنم...گراف فلش‌کارت های مرور‌شده در Anki برای نویسندهتعهد: شرط اول بهبود حافظهدرست است که در این تکنیک هر روز باید مرور کرد، اما اگر به آن متعهد بمانید تضمین می‌کنم که یک حافظه خوب در انتظارتان خواهد بود! اغلب کاربران به طور میانگین بیست دقیقه در روز برای مرور فلش‌کارت‌ها وقت می‌گذارند. اگر کارت جدید اضافه نکنید (که در آن صورت باید بگویم تنبل‌خان، برو کارت‌هایت را اضافه کن) میانگین مدت مرورتان کم کم به صفر میل خواهد کرد؛ زیرا همه اطلاعاتی که وارد می‌کنید به مرور وارد حافظه بلندمدت می‌شود. دانستن این که با اضافه کردن اطلاعات به Anki دیگر آنها را از یاد نخواهید برد، اعتمادبنفسی به آدم می‌دهد که دیوانه‌کننده است.کارت‌های Anki نویسنده و فواصل یادآوری آن‌هاجمع‌بندیتکرار فاصله‌دار مهم‌ترین کاری است که برای بهبود زندگی/شغلم کرده‌ام. متعهد ماندن به آن همیشه کار ساده‌ای نیست. انجام دادنش تضمین نمی‌کند که مهندس بهتری شوید (استفاده از بهترین روش‌ها و طراحی‌‌ها نتیجه‌بخش‌تر از سینتکس است)، اما شما را مهندس تواناتری خواهد کرد. باورنکردنی است که وقتی آدم می‌تواند سریع سینتکس را به یاد بیاورد، چقدر کد زدنش سریع‌تر می‌شود. بله، بعضی‌وقت‌ها هم نتیجه کار یک کد سریع افتضاح است، اما بهترین کدنویس‌ها آنهایی‌اند که زیاد کد می‌زنند. زیاد کد زدن تنها راه تضمینی برای پیشرفت است.از طرف دیگر، مغز ما اطلاعات متنوع و بی‌ربط را یک جور خیلی جالب و غیرمستقیمی با هم ترکیب می‌کند. خیلی از فلش‌کارت‌های من از پست‌های وبلاگی و مقالات مهندسی هستند، اما دانستن تاریخچه RPC، SOAP، REST، و GraphQL باعث شده در طراحی و ساختار بهتر عمل کنم و تصمیمات مفید‌تری بگیرم. البته خب، هنوز نفهمیده‌ام حفظ کردن الگوریتم‌های درخت جستجوی دودویی کجا قرار است به کارم بیاید!و اما... در مسیر برنامه نویس ده‌برابری!کل این قضیه با این آرزوی نامعقول من شروع شد که می‌خواستم یک «برنامه‌نویس ده‌برابری» بشوم. انگار با خودم فکر می‌کردم قرار است به جایی برسم که برایم جشن فارغ‌التحصیلی بگیرند، مدرکم را دستم بدهند و بگویند «تبریک‌! از حالا به بعد دیگه تو یه برنامه‌نویس ده‌برابری شدی!». آرزوی مسخره‌ای است. البته خب، اگر جایزه «دارنده بهترین راهکار سال» را به من بدهند خیلی هم بدم نمی‌آید!حالا متوجه‌ شده‌ام که واقعا نمی‌دانم برنامه‌نویس ده‌برابری بودن یعنی چه. هیچ معیار سنجشی نیست که با آن بشود میزان خروجی، قدرت رهبری، کیفیت کد، و بدهی فنی (Technical Debt) را یکجا سنجید. وقتی که بلاخره احساس کردم دارم در خودم پیشرفت ایجاد می‌کنم، دیگر رفتن به دنبال «ده‌برابری» شدن برایم بی‌معنی شد. با بهتر کردن حافظه‌ام، کنترل سرنوشتم را در دستان خودم گرفتم.کایل هنوز هم چند برابر بهتر از بهترین حالت من است، اما من دیگر مشکلی با این قضیه ندارم.ترجمه بر اساس: "Chasing 10X: Leveraging A Poor Memory In Engineering" by Jeffrey Shek @ Senriganکوئرامگ مجله‌ای تخصصی برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید توئیتر یا کانال تلگرام ما را دنبال کنید. مریم مقدس برهان مریم مقدس برهان Mon, 15 Jul 2019 12:06:37 +0430 https://virgool.io/Quera-Mag/%D8%A8%D8%AF%D9%87%DB%8C-%D9%81%D9%86%DB%8C-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%BE%D8%B1%D9%88%DA%98%D9%87-cubbj5smg8pi در دنیای ایده‌آل من، همه پروژه‌ها همیشه به موقع تمام می‌شوند و هیچ وقت خرجشان از بودجه تخمینی بیشتر نمی‌شود. تازه با همان بودجه، تیم‌ها نه تنها می‌توانند Featureهای اضافه بسازند، که می‌توانند قبل از بیرون دادن نسخه نهایی همه چیز را چندین بار هم تست کنند. اما حیف، دنیای واقعی این‌قدرها هم دلنشین نیست؛ بلکه در فرآیند توسعه نرم‌افزار، با هر قدمی که می‌گذاریم مشکلات جدیدی از چپ و راست جلوی پایمان سبز می‌شوند. یکی از رایج‌ترین و همه‌گیرترین این مشکل‌ها، بدهی فنی (Technical Debt) است. بدهی فنی چیست؟بدهی فنی، کارهای تکمیلی‌ای است که برای کامل کردن فرآیند توسعه نرم‌افزار، زمانی در آینده باید آنها را انجام بدهیم. بدهی فنی نتیجه عجله کردن در تحویل کارکرد یا پروژه‌ای است که در آینده، نیاز به بازسازی خواهد داشت. به عبارت دیگر، پیامد اولویت دادن تحویل سریع به نوشتن کد ایده‌آل است.بدهی فنی مثل بدهی بانکی است؛ اگر به موقع پرداختش نکنیم، جریمه می‌شویم و بدهی‌مان از قبل هم بیشتر می‌شود. بی‌توجهی به بدهی‌های فنی باعث می‌شود عملکرد نرم‌افزار ضعیف شود، تغییر دادن آن سخت یا حتی غیرممکن باشد، و احتمال ایراد پیدا کردن برنامه بعد از هر بروزرسانی بیشتر و بیشتر شود. اما همانطور که با وام گرفتن می‌شود سریع‌تر به اهداف بزرگ زندگی رسید، بدهی‌های فنی هم الزاماً بد نیستند. اگر آنها را درست مدیریت کنید، مزایای بی‌نظیری برای شرکت‌تان خواهند داشت؛ بخصوص اگر از آن شرکت‌هایی باشید که رشد سریع دارند. در چنین شرکتی باید محصولات را سریع و زودبه‌زود ارائه کنید تا بتوانید تناسب محصول/بازار را پیدا کرده، نیازهای مشتری را برآورده کنید، و از فرصت‌هایی که سر راهتان پیش می‌آید بهره ببرید. با مدیریت بدهی فنی، تضمین خواهید کرد که حرص دویدن، در بلندمدت زمینتان نخواهد زد.درست است که هیچ دستورالعملی برای همه آدم‌های روی کره زمین جوابگو نیست، اما به نظر می‌رسد آشنایی با انواع بدهی‌های فنی، به تیم‌ها کمک می‌کند تا در مورد بدهی فنی حرف بزنند و مشکلات مربوط به آن را به شکل بهتری حل کنند.دگ لیودن (Dag Liodden)، کوفاندر و CTO شرکت فناوری تبلیغاتی تپ‌اد (Tapad) بیشتر از ۱۴ سال است که دارد با بدهی فنی سر و کله می‌زند؛ در ادامه نگاهی می‌اندازیم به سه نوع اصلی بدهی فنی که توسعه‌دهندگان بیشتر از همه با آن‌ها سروکار دارند و استراتژی‌هایی که دگ لیودن برای روبه‌رو شدن با هر کدام پیشنهاد می‌کند را مرور می‌کنیم:۱. بدهی فنی عامدانهبدهی فنی و عواقب آنمهندس‌ها معمولا خودشان می‌دانند که کدام راه، راه درست انجام کار است و کدام راه، راه سریع آن. خیلی وقت‌ها، راه سریع همان کار درست است (برای جلوگیری از Over-engineering)، اما بعضی وقت‌ها هم اعضای تیم عمداً کار «اشتباه» را انجام می‌دهند، چرا که باید محصول را به سرعت به بازار برسانند.برای رساندن محصول به بازار، گاهی اوقات مجبورید خودتان عمداً بدهی فنی‌تان را زیاد کنید. وقتی این مسیر را در پیش می‌گیرید، فقط به زمانی که در آن صرفه‌جویی کرده‌اید فکر نکنید؛ بلکه به این هم بیندیشید که برای بازپرداخت بدهی‌ای که ایجاد کرده‌اید در آینده چه باید بکنید. مطمئن شوید که ذی‌نفعان محصول می‌دانند که این صرفه‌جویی، منجر به کاهش سرعت آماده شدن Featureهای دیگر در آینده خواهد شد.راه حل: شاید بگویید که این کار خیلی با فرهنگ چابک (Agile) تیم شما سازگار نیست! اما ایده خوبی است که وقت ایجاد این نوع از بدهی فنی، کارهایی که انجام نداده‌اید را در بک‌لاگ محصول (Backlog) یادداشت کنید. اگر این کارهای ناتمام به طور مشخص ثبت نشوند، بعید است که بدهی فنی در آینده پرداخت شود. بدون پرداخت بدهی‌ها، در گذر زمان بدهی فنی عامدانه تبدیل به بدهی ناشی از طراحی اتفاقی خواهد شد. مسئولیت به وجود آمدن این نوع بدهی‌ها بر عهده مالک محصول‌ (Product Owner) و ذی‌نفعان است؛ زیرا به خاطر تصمیمات تجاری است که به وجود می‌آیند.۲. بدهی فنی ناشی از طراحی تاریخ‌گذشته یا اتفاقیهنگام طراحی سیستم‌های نرم‌افزاری، سعی کنید بین «آینده‌نگری در کدنویسی» و «سادگی و سرعت تحویل» تعادل برقرار کنید. کار سختی است، و هر کسی گاهی در آن شکست می‌خورد. با گذر زمان، رشد سیستم، و تغییر نیازها، ممکن است به این نتیجه برسید که طراحی کارتان مشکل دارد و یا اینکه ایجاد یک کارکرد جدید تبدیل به کاری سخت و کند شده است. در یک طراحی خوب و اصیل، Refactor یا بازسازی تدریجی کدها خیلی آسان‌تر خواهد بود. اما بعضی وقت‌ها هم چاره‌ای نیست؛ باید خون دل خورد، نشست و یک دور Refactor مفصل و پر و پیمان انجام داد.راه حل: اینکه چطور Refactor مفصلی بکنیم خودش چندین پست جدا می‌طلبد، اما نیاز به انجام آن یک چیز طبیعی است. هرچند وقت یک بار، مثلا هر دو سال یک بار یا هر وقت که سیستم در وضعیت باثباتی بود، لازم است که چنین کاری انجام شود. اگر نشود، آنوقت ممکن است Over-engineering کنید و باعث شوید سیستم به شکل غیر ضروری‌ای مرتباً کند باشد. رهبران تیم و مالک محصول‌ها باید اطمینان حاصل کنند که برای بازپرداخت این نوع بدهی در آینده زمان کنار می‌گذارند؛ چرا که علت به وجود آمدن آن، تصمیمات مربوط به طراحی سیستم و تغییر مداوم نیازهای سیستم است.۳. بدهی فنی ناشی از فرسودگی نرم‌افزاریفرسودگی سیستم و بدهی فنی متعاقب آنبدهی فنی ناشی از فرسودگی نرم‌افزاری (Bit rot)، به مرور زمان به وجود می‌آید. تغییراتی که به تدریج در یک Component یا یک سیستم ایجاد می‌کنیم، باعث می‌شوند که کم‌کم سیستم پیچیدگی‌های غیرضروری‌ای پیدا کند. این پیچیدگی بخصوص زمانی تشدید می‌شود که چندین نفر بدون اینکه طراحی اولیه سیستم را درست فهمیده باشند، روی آن کار کنند. از جمله علایم چنین حالتی، برنامه‌نویسی کپی‌پیستی (یا به عبارتیCargo Cult Programming) است.راه حل: این تنها نوع از بدهی‌های فنی است که باید با Refactor مداوم کدها، به کلی از آن اجتناب کرد. تیم‌هایی که قوی هستند، برای فهم طراحی سیستمی که رویش کار می‌کنند، وقت کافی می‌گذارند؛ حتی اگر طراحی اولیه آن کار خودشان نبوده باشد. آنها به مرور طراحی را بهبود می‌بخشند و در طول مسیر، کدهای بد را تمیز می‌کنند. مسئولیت جلوگیری از به وجود آمدن این نوع بدهی با تیم توسعه نرم‌افزار است، زیرا این تک‌به‌تک اعضای توسعه‌دهنده هستند که آن را به وجود می‌آورند.تقسیم‌بندی انواع بدهی فنی یک راه حل معجزه‌آسا نیست. اینطور نیست که چوبدستی را تکان بدهیم و فقط با طبقه‌بندی، مدیریت کردن بدهی به طور جادویی آسان شود. اما این کار، تیم شما را قدرتمندتر می‌کند و گفتگوهای مفیدتری در این‌باره خواهید داشت. بدهی فنی شما به سیستم هرگز تمام نخواهد شد، و نباید هم بشود. نکته مهم این است که همیشه حواستان باشد که این بدهی چطور باعث کندی تیمتان می‌شود، و سعی کنید بین «تحویل Featureها در کوتاه‌مدت» و «افزایش بازدهی کلی در میان‌مدت و بلندمدت»، تعادل برقرار کنید.ترجمه و اقتباس از:"There are 3 main types of technical debt. Here’s how to manage them" @ Hackernoon“What Technical Debt Is and How to Calculate It” @ DZone“What is Technical Debt?” @ ProductPlanکوئرامگ: نسخه کارفرما، مجله‌ای تخصصی برای مدیران منابع انسانی و مدیران فنی سازمان‌ها است که به شکل ماهانه با مطلب‌هایی در زمینه چالش‌های منابع انسانی در حوزه برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید کوئرا را در لینکدین دنبال کنید. مریم مقدس برهان مریم مقدس برهان Tue, 18 Jun 2019 19:33:10 +0430 https://virgool.io/Quera-Mag/%D8%B1%D8%A7%D9%87%DA%A9%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D9%85%D8%A8%D8%AA%D9%86%DB%8C-%D8%A8%D8%B1-%D9%81%D8%B1%D8%A7%D9%86%D8%AA%D8%A7%D9%86%D8%AF-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%A8%D9%87%D8%A8%D9%88%D8%AF-%DA%A9%D8%A7%D8%B1%D8%A7%DB%8C%DB%8C-%D8%A7%D9%BE%D9%84%DB%8C%DA%A9%DB%8C%D8%B4%D9%86-qdfregtuvt5y کریاکاکیس، فری‌کدکمپ — اگر Load شدن وبسایت‌تان بیشتر از ۳ ثانیه طول بکشد، حدوداً نصف بازدیدکننده‌هایتان را از دست خواهید داد! (مشاهده پژوهش Google) طولانی شدن زمان لودینگ، تاثیر ویران‌کننده‌ای بر نرخ تبدیل (Conversion Rate) اپلیکیشن شما خواهد داشت. در طرف مقابل کارایی بهینه اپلیکیشن (Performance) نقش کلیدی در موفقیت محصول دارد؛ به عنوان مثال با کاهش زمان لودینگ، مشتری‌هایتان تجربه باکیفیت‌تری خواهند داشت، نرخ تبدیل بهتر می‌شود و وضعیت سئو بهبود می‌یابد!بیایید فرض کنیم که با یک فریم‌ورک مدرن جاوا اسکریپت (مثلاً Angular ،React ،VueJS یا...) سمت فرانت‌اند یک اپلکیشن یا وبسایت را ساخته‌ایم. حالا باید چه کار کنیم تا عملکرد این اپلیکیشن، تبدیل به مانعی در سر راه موفقیت آن نشود؟> اندازه‌گیری عملکرد وبسایت یا اپلیکیشناول از همه، باید یک جوری داده جمع کنیم. من برای سنجش عملکرد Front-end، به این دو ابزار از همه بیشتر اعتماد دارم:لایت‌هاوس (Lighthouse) گوگل کروماسپیدکرو (Speedcurve)با هر دوی این ابزارها می‌توان وضعیت همه شاخص‌های کلیدی عملکرد یا همان KPIها را تعقیب کرد؛ یعنی شاخص‌های کارایی همچون:مقیاس سرعت صفحه (Pagespeed Index)زمان مانده به استفاده (Time to Interactive)و اولین نشانه از محتوا (First Contentful Paint).لایت‌هاوس به طور پیش‌فرض در بخش Developer Tools مرورگر کروم قرار گرفته است. این ابزار، وبسایت یا اپلیکیشن وب ما را تحلیل می‌کند و راهنمایی‌های خیلی مفیدی برای بهتر کردن عملکرد آن ارائه می‌دهد.لایت‌هاوس کروم، راهنمایی‌های مفیدی برای توسعه‌دهندگان دارد!اگر از اسپیدکرو استفاده کنیم، نه تنها می‌توانیم همه این شاخص‌ها را داشته باشیم، که می‌توانیم تغییرات آنها را در گذر زمان ببینیم. خب، حالا که توانستیم میزان موفقیت‌مان را اندازه بگیریم، وقت آن رسیده که برویم سراغ بهینه‌سازی اصلی‌ترین بخش‌های وبسایتمان!> بهینه‌سازی عکس‌هاعکس‌ها از مهم‌ترین عناصر هر وبسایت هستند. به طور میانگین، بیش از ۶۰٪ دیتایی که روی صفحات وب لود می‌شود، متعلق به عکس‌هاست. وقتی تصاویر اینقدر مولفه‌های اساسی‌ای هستند، بهینه‌سازی آنها در نظر من مهم‌ترین و در عین حال راحت‌ترین کاری است که می‌شود انجام داد!۱. تغییر اندازه عکس‌ها و واکنش‌گرا (Responsive) کردن آن‌هامهم‌ترین سوالی که باید جواب دهیم، این است که آیا Resolution عکس‌هایی که داریم، در همان حد مورد نیاز است یا بیشتر از آن؟ اگر بیشتر است، پس باید اندازه عکس را طوری تغییر بدهیم که برای Layout صفحه مناسب باشد.اگر Layout واکنش‌گرا می‌خواهید، باید عکس‌هایتان را واکنش‌گرا کنید!علاوه بر این، باید مطمئن شویم که عکس‌های ما به اندازه Layout ما واکنش‌گرا هستند. واکنش‌گرا بودن یعنی اینکه کاربر از هر دستگاهی که استفاده کرد، عکس‌ها به رزولوشن، اندازه، و دیگر ویژگی‌های متناسب با همان دستگاه در بیایند. من اخیرا ابزار خیلی خوبی برای این کار پیدا کرده‌ام که اسمش Responsive Image Breakpoints Generator است. با این ابزار هم می‌شود عکس را در همه اندازه‌های مختلفی که لازم است تولید کرد، و هم کد HTML5 لازم برای کار گذاشتن عکس‌ها را تحویل گرفت. من معمولاً ترجیح می‌دهم که هشت تا ده نسخه مختلف از عکسم را تولید کنم.بدیهی است که کد HTML5 تولید شده را می‌توانید در هر وبسایت یا اپلیکیشنی که بخواهید، استفاده کنید. همچنین اگر از گالپ (gulp) خوشتان می‌آید، می‌توانید با پلاگین gulp-responsive کاری کنید که این فرآیند به طور خودکار انجام شود.۲. لود تنبل عکس‌ها یا Lazy Loadingلود تنبل (Lazy Loading) یعنی این که لود شدن عکس‌های غیرضروری را عقب بیندازیم. معمولاً اگر عکسی در Viewport فعلی جلوی چشم کاربر نباشد، می‌توان لود کردنش را به زمانی دیگر موکول کرد: مثلاً به زمانی که عکس وارد Viewport شده یا در حال وارد شدن به آن است.از هر فریم‌ورکی که استفاده کنیم، همیشه پلاگینی هست که با آن عکس‌هایمان Lazy Load شوند (مثلا v-lazy-images در VueJS). البته می‌توانیم خودمان هم Implementation خودمان را داشته باشیم. فقط باید مطمئن شویم که برای تشخیص زمان ورود یا خروج یک المان به Viewport، از روش مدرن استفاده می‌کنیم: یعنی از IntersectionObserver API.۳. استفاده از شبکه تولید محتوا (CDN) برای رساندن عکس‌ها به مخاطبحالا که اندازه و تعداد تصاویر وبسایتمان را به حالت بهینه رسانده‌ایم، می‌توانیم از CDN (شبکه تحویل محتوا) برای رساندن آنها به کاربران استفاده کنیم؛ بخصوص اگر قرار باشد که مردم از طیف وسیعی از موقعیت‌های جغرافیایی به سایت ما سر بزنند!خلاصه بگویم، CDN شبکه سرورهایی در سرتاسر جهان دارد و عکس‌های شما را روی آن Cache می‌کند. بنابراین اگر کاربری از استرالیا بخواهد عکس وبسایت شما را ببیند، دیگر لازم نیست از سرور شما در ایران به آن دسترسی پیدا کند؛ بلکه CDN همان عکس را از سروری که به استرالیا نزدیک‌تر است، برایش لود می‌کند. با این کار، مدت زمان تاخیر چرخشی (RTT) لازم برای لود کردن تصویر خیلی کمتر می‌شود.> بهینه‌سازی‌های سمت CSS، HTML و JSهمه فریم‌ورک‌های جدید وقت انجام Production Build، کد داده شده را بهینه‌سازی می‌کنند؛ مثلاً با Code-splitting ،Tree-shaking و Minification. اما غیر از این چه کارهایی می‌توانیم انجام بدهیم؟ ****۱. بهینه‌سازی متن اصلی HTMLتقریباً همه اپلیکیشن‌های وب را HTML سر پا نگه می‌دارد. وقتی می‌خواهیم در متن HTML خود به Resourceها ارجاع بدهیم، بهتر است این دو تا کار را فراموش نکنیم:یک. ارجاعات CSS را بالای هدر متن HTML قرار دهیم تا حتماً رندر Progressive انجام شود. دو. Attributeهای جاوا اسکریپت را زیر بدنه HTML قرار داده و اسکریپت‌(ها) را به شکل غیر همزمان (Async) لود کنیم. با این کار، تگ‌های نمی‌توانند مانع رندر HTML شوند.۲. حذف لود کردن‌های غیرضروریماژول‌ها و مولفه‌های لود تنبل (Lazy Loading)هم Angular، هم React و هم VueJS همگی امکاناتی برای لود کردن تنبل‌وار دارند. فقط باید کدمان را درست و متناسب با نیاز خودمان تقسیم کنیم، یعنی طوری که فقط ماژول‌هایی که لازم داریم لود شوند؛ آن هم فقط زمانی که واقعاً به لود شدنشان نیاز است. به عنوان مثال، اگر اپلیکیشنی برای تجارت الکترونیکی ساخته باشیم، ماژول‌های Basket یا Payments نباید وقتی کاربر در صفحه "خانه" قرار دارد، لود شوند.> فشرده‌سازی و Cachingبه طور کلی، باید همه Assetهایی که برای فرانت‌اند ضروری هستند (هم عکس و هم کد) را به خوبی فشرده و Cache کنیم.با فشرده‌سازی فایل‌ها، Assetهای اپ کمی سبک‌تر می‌شوند و زمان تاخیر چرخشی لازم برای ارائه آنها کاهش پیدا می‌کند. یکی از رایج‌ترین روش‌ها برای فشرده‌سازی فایل‌ها، استفاده از جی‌زیپ (Gzip) است. جی‌زیپ برای کوچک‌کردن قطعه‌های کد، متن‌ها، عکس‌ها، و فایل‌های صوتی خیلی خوب است. یک الگوریتم دیگر برای فشرده‌سازی فایل‌ها، براتلی (Brotli) است که مرتباً به محبوبیتش اضافه می‌شود. این الگوریتم متن باز را مهندسین نرم‌افزار گوگل و دیگر شرکت‌ها مرتباً به روز می‌کنند. براتلی ثابت کرده که فایل‌ها را با نسبت (Ratio) خیلی بالاتری فشرده می‌کند.مهم نیست از اِنجین‌اِکس (Nginx) استفاده کنیم یا آپاچی یا هر وب‌سرور دیگر. در همه وب‌سرورها، به راحتی می‌توانیم روش فشرده‌سازی مورد علاقه خود را با تغییر دادن فایل‌های Configuration، فعال کنیم (فعال کردن براتلی در Nginx، یا فعال کردن براتلی در Apache).و اما Caching! رایج‌ترین تکنیک برای Caching که اتفاقا لایت‌هاوس هم آن را توصیه می‌کند، روش Leverage Browser Caching است. این را هم می‌شود با تغییر دادن فایل‌های Configuration سرور، فعال کرد (فعال کردن Leverage Browser Caching)جمع‌بندیدر سمت فرانت‌اند وب‌سایت‌ها و اپلیکیشن‌ها، بحث کیفیت عملکرد و کارایی بحث خیلی مهمی است و باید آن را جدی گرفت. امیدوارم با خواندن این مقاله، با مهم‌ترین کارهایی که می‌شود برای بهبود عملکرد اپلیکیشن‌ها انجام داد آشنا شده باشید و بتوانید خودتان این تغییرات را اعمال کنید.اگر دوست دارید چک‌لیست مفصل‌تری در این باره ببینید، به اینجا بروید.بر اساس:How to boost your front-end application’s performance > by Dimitris Kiriakakis @ freeCodeCamp کوئرامگ مجله تخصصی کوئرا برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید توئیتر یا کانال تلگرام ما را دنبال کنید. مریم مقدس برهان مریم مقدس برهان Mon, 13 May 2019 18:55:53 +0430 https://virgool.io/Quera-Mag/%D8%A8%D9%87%D8%AA%D8%B1%DB%8C%D9%86-%D9%88%DB%8C%D8%B1%D8%A7%DB%8C%D8%B4%DA%AF%D8%B1%D9%87%D8%A7%DB%8C-%D9%85%D8%AA%D9%86-%D8%AD%D8%A7%D9%84-%D8%AD%D8%A7%D8%B6%D8%B1-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87%D9%86%D9%88%DB%8C%D8%B3%D9%87%D8%A7-vqfwac2vu8h1 ویندوز و مک خودشان ادیتورهای ساده دارند؛ اما اگر یک وب دولوپر حرفه‌ای باشید، TextEdit و Notepad برای شما کافی نیست. خوشبختانه در این دنیا آن چیزی که کم نیست، ویرایگشر متن برای کد زدن است‌! آنچه که در این پست می‌بینید، مجموعه‌ای است از بهترین ویرایشگرهای مجانی و پولی در سال ۲۰۱۸ برای توسعه‌دهنده‌ها!چرا به ویرایشگر پیشرفته‌تری نیاز داریم؟توسعه‌دهنده‌های وب یا نرم‌افزار وقتی می‌خواهند فایلی بسازند یا آن را تغییر بدهند، از ویرایشگر استفاده می‌کنند. اگر فرمت فایل را ندانید، می‌توانید آن را در ویرایشگر باز کنید و سورس کدش را ببینید. اگر بخواهید استایل‌ها، فونت‌ها، و لینک‌ها را از متنی حذف کنید، ویرایشگر دوست خوب شماست. ولی اینکارها را با همان ویرایشگرهای پیش‌فرض ویندوز و مک هم می‌شود انجام داد. مسئله آنجاست که بخواهید وب‌سایت‌ها یا نرم‌افزارهای پیچیده بسازید؛ در اینجاست که یک ویرایشگر پیشرفته، می‌تواند کارتان را حسابی راحت‌تر کند.بهترین ویرایشگرها برای کار اشتراکیبعضی از ویرایشگرهای مبتنی بر وب هستند که هدف از ساخت آنها، کار اشتراکی بوده است. از این ادیتورها می‌توانید برای سنجش افراد در مصاحبه استفاده کنید، در جلسه کدزنی تیمی از آنها بهره ببرید، یا اینکه به راحتی با همدیگر کد به اشتراک بگذارید.۱. کدشر (CodeShare)کدشِر اولین سرویسی است که برای در لحظه به اشتراک گذاشتن کدها ساخته شده است. این ویرایشگر مفید، برای استخدام افراد دورکار، مرور و بررسی کدها، دیباگ کردن و کارهایی از این دست حسابی به درد می‌خورد. وجه متمایز کدشِر این است که با آن می‌توانید روی ویدیو حرف بزنید؛ قابلیتی که بعضی جاها خیلی به کار می‌آید!برای استفاده از کدشِر، باید کدتان را از محیط توسعه شخصی‌تان به محیط کدشِر پورت کنید. در ضمن، مگر در حالتی که اکانت ساخته باشید، کد شما فقط به مدت ۲۴ ساعت ذخیره خواهد شد.۲. کد اِنی‌ور (Codeanywhere)کد اِنی‌ور قابلیت‌های فراوانی دارد و برای کد زدن از راه دور یا از بیرون شرکت خیلی مناسب است. کار کردن با ویرایشگر کد اِنی‌ور خیلی ساده و زودفهم است، با آن می‌توانید به شکل دورکاری با بقیه ارتباط برقرار کنید، کنسول ترمینال در آن جایگذاری شده، و می‌شود ویرایش‌های انجام شده روی متن را مشخص و تعقیب کرد.با کد اِنی‌ور، به راحتی می‌توانید برای فایل‌ها یا حتی کل فولدر یک پروژه، لینک بسازید و آن را با هرکدام از اعضای تیم که می‌خواهید، به اشتراک بگذارید. نسخه آزمایشی کد اِنی‌ور تنها برای هفت روز مجانی است. نسخه‌های پولی آن متنوعند و بسته به امکاناتی که ارائه می‌دهند، قیمتشان از ۲ دلار تا ۴۰ دلار در ماه می‌رسد.۳. کدپن (CodePen)کدپن را به عنوان یک پلتفرم عالی برای کار ‌اشتراکی می‌شناسند. شما می‌توانید “Pen”هایتان (یک قطعه کد) را مستقیما روی این پلتفرم بسازید و به اشتراک بگذارید. کدپن یک حالت Collab Mode هم دارد که در آن، شما و دیگر اعضای تیم می‌توانید همگی همزمان یک Pen را ویرایش کنید.برای استفاده از Collab Mode، سازنده Pen باید نسخه Pro را خریداری کرده باشد؛ اما دیگر اعضایی که روی آن Pen کار می‌کنند لازم نیست برای ویرایش کردن پول بدهند. علاوه بر این، در Collab Mode قابلیت چت هم وجود دارد که با آن می‌توانید به شکل آنی با تیمتان در مورد تغییرات اعمال شده صحبت کنید.بهترین ویرایشگرهای رایگان سال ۲۰۱۸همه این ویرایشگرها از زبان‌های برنامه‌‌نویسی اصلی پشتیبانی می‌کنند، اما هیچ‌کدام از آنها برای کار کردن با همه زبان‌ها ساخته نشده است. قبل از دانلود هر ویرایشگر، اول سایت سازنده‌اش را چک کنید تا مطمئن شوید که از زبان مورد نظر شما پشتیبانی می‌کند. اگر بخش عمده کاری که می‌کنید توسعه وبسایت است، این ویرایشگرها کارتان را راه می‌اندازند.۱. اتم (Atom)اتم ادیتور نسبتا جدیدی است که در سال ۲۰۱۵ منتشر شده، متن‌باز است و در مک، ویندوز و لینوکس کار می‌کند. نه تنها اتم را می‌توان حسابی شخصی‌سازی (Customize) کرد، که جمعی از دولوپرهای متعهد هم مرتب دارند برایش وقت و انرژی می‌گذارند. این یعنی اینکه شما به مجموعه‌ بزرگی از پلاگین‌ها و تم‌ها برای ادیتورتان دسترسی خواهید داشت. حتی می‌توانید با ابزاری که در خود اتم تعبیه شده، خودتان هم پلاگین بسازید. از آنجایی که این ادیتور فقط با فناوری‌های وب مثل HTML، جاوااسکریپت و CSS ساخته شده است، وب دولوپرهای حرفه‌ای کاملا با آن احساس راحتی خواهند داشت.۲. ویژوال استودیو کد (Visual Studio Code)ویژوال استودیو کد هم مثل اتم در سال ۲۰۱۵ منتشر شده، اما در همین مدت کوتاه کلی طرفدار پیدا کرده است. این ویرایشگر متنی در پلتفرم‌های مختلف اجرا می‌شود، اکوسیستم عظیمی از پلاگین‌ها دارد، و قابلیت‌های هیجان‌انگیزی در آن هست که زندگی را ساده‌تر می‌کنند؛ از جمله:تعبیه شدن فرمان‌های Git در ویرایشگرداشتن IntelliSense که با قابلیت تکمیل هوشمند، پا را از هایلایت کردن کد و خودتکمیلی (Auto-completion) فراتر می‌گذاردانجام دیباگینگ مستقیما از خود ادیتورویژوال استودیو کد از ویرایشگرهای پرطرفداری مثل اتم سریع‌تر است. علاوه بر این، اگر بخواهید موقع کار حواستان پرت چیزهای دیگر نشود، می‌توانید قابلیت Zen Mode را در این ویرایشگر فعال کنید. این قابلیت همه منو‌ها و پنجره‌ها را از دید پنهان می‌کند و فقط خود ویرایشگر را به شما نشان می‌دهد.۳. برکتز (Brackets)سازندگان برکتز، آن را برای دولوپرهای وب ساخته‌اند. در نتیجه، برکتز هم برای لینوکس، هم ویندوز و هم برای مک نسخه دارد. گول UI ساده‌اش را نخورید؛ برکتز از کلی میانبر کیبورد پشتیبانی می‌کند و با قابلیت‌های پیشرفته‌ای همچون ویرایش با صفحه نمایش دونیم شده (Split-screen)، گزینه‌ای حرفه‌ای است. با قابلیت Live Preview، می‌توانید در همان حین که دارید فایل CSS یا HTML را ویرایش می‌کنید، تغییرات صفحه وب نهایی را در لحظه ببینید. پلاگین‌های برکتز هم پشتیبانی از چیزهای دیگری همچون اعتبارسنجی W3C (W3C Validation) و ابزارهای پایتون را به نرم‌افزار اضافه می‌کنند.۴. نوت‌پد پلاس پلاس (Notepad++‌)نوت‌پد پلاس پلاس نسخه ارتقایافته‌ی دوست قدیمی‌مان نوت‌پد در ویندوز است. این برنامه نه تنها همه کارهای نوت‌پد را انجام می‌دهد، که کلی هم از آن فراتر می‌رود. شما می‌توانید فایل‌ها را در تب‌های جداگانه باز کنید و بدون اینکه نیازی به باز و بسته کردن مداوم فایل‌ها باشد، به ویرایش چند فایل مختلف بپردازید. حتی می‌توانید همه تب‌ها را همزمان تحت کنترل بگیرید و به این ترتیب به راحتی به مقایسه متن آنها، سرچ، و Replace بخش‌های مختلف بپردازید. نوت‌پد پلاس پلاس فقط با ویندوز کار می‌کند، که البته انتظاری جز این هم نمی‌شد داشت‌! اما خوبی‌اش این است که نسخه موبایل هم دارد. همچنین انبوهی از پلاگین‌ها برای این ویرایشگر ساخته شده که می‌توانید با دانلود آنها، قابلیت Auto-save را راه بندازید، متن چند فایل‌ مختلف را با هم در یک فایل ترکیب کنید، و کلی کار دیگر انجام دهید.۵. تکست‌میت (TextMate)تکست‌مِیت ویرایشگر خیلی خوبی است که منحصرا برای کاربران Mac ساخته شده است. این ابزار که جایزه Apple Design را هم برده، همه قابلیت‌هایی که انتظار دارید داشته باشد را دارد؛ از جمله سرچ و Replace، ایجاد فرورفتگی خودکار در اول خط، و خودتکمیلی. شما می‌توانید در تکست‌مِیت با هر زبانی که می‌خواهید کد بزنید، اما خود این ادیتور ابزار منحصر بفردی هم برای ساختن پروژه‌های Xcode دارد.۶. ویم (Vim)ویم در سال ۱۹۹۱ منتشر شد و آن موقع، یکی از بهترین ادیتورها بود. بنابراین این که حالا در لیست سال ۲۰۱۸ هم قرار گرفته، نشان می‌دهد که چقدر برنامه خوبی است. توسعه‌دهنده‌ها هنوز هم برای ویم اسکریپت‌های جدید می‌دهند و آن را به روز رسانی می‌کنند. به خاطر عمر طولانی‌ای که ویم داشته، به راحتی می‌شود برایش مستند‌سازی‌ و راهنمای کار پیدا کرد. ویم روی همه پلتفرم‌های اصلی کار می‌کند.برای دیدن مجموعه کاملی از فرمان‌های Vim، می‌توانید این صفحه را ببینید.۷. کومودو ادیت (Komodo Edit)با کومودو ادیت می‌شود تب‌های متعدد باز کرد و علاوه بر این، کلی تنظیمات مختلف هم برای UI دارد تا ویرایش را تا جایی که می‌شود، راحت کند. به عنوان مثال، با قابلیت Focus Mode، همه پنجره‌های باز پنهان می‌شوند تا شما همه تمرکزتان را روی کد زدن بگذارید و حواستان پرت نشود. با تنظیم یک قابلیت دیگر، می‌توانید فولدرها را در کناره‌ی ادیتور مشاهده کنید. یک قابلیت دیگر که واقعا به درد بخور است اما کم از آن صحبت می‌شود، دکمه‌ای است که با زدن آن نشانگر موستان به جای قبلی‌اش برمی‌گردد. اگر کارکردهای پیشرفته‌تری مثل اشکال‌زدایی (Debugging)، آزمایش واحد (Unit Testing) و بازسازی کد (Refactoring) می‌خواهید، به این ادیتور نگاهی بیاندازید.بهترین ویرایشگرهای پولیچند ویرایشگر خوب دیگر هم وجود دارند که عمدتاً پولی هستند. البته بعضی از آن‌ها نسخه رایگان هم دارند که قابلیت‌های کمتری دارد. از آنجایی که در ایران این ویرایشگرها چندان مقرون‌به‌صرفه نیستند، از معرفی جزئیات آن‌ها صرف نظر کردیم و تنها به ذکر فهرستی از آن‌ها بسنده می‌کنیم:۱. سابلایم تکست (Sublime Text)۲. کافی‌کاپ اچ‌تی‌ام‌ال (CoffeeCup HTML)۳. کدا (Coda) برای مک یا اولترا ادیت (UltraEdit) برای ویندوز۴. بی‌بی‌ ادیت (BBEdit)جمع‌بندیاگر تازه وارد دنیای برنامه‌نویس‌های وب شده‌اید، با ویرایشگرهای متن‌باز مثل اتم یا برکتز شروع کنید. خیلی از ویرایشگرهای رایگان آنقدرها پیشرفته هستند که برای اغلب پروژه‌های ساخت صفحه وب کفایت ‌کنند. وقتی در کد زدن پیشرفت بیشتری کنید و به خودتان مطمئن‌تر شوید، ممکن است به نظرتان بیاید که این ویرایشگرها زیادی آدم را محدود می‌کنند. در این جاست که ممکن است نسخه‌های پولی جذاب‌تر به نظر برسند؛ زیرا اگر کمک کنند که کارتان را سریع‌تر و بهینه‌تر انجام دهید، احتمالا ارزش هزینه‌ای که می‌کنید را دارند.ترجمه‌ای از:"A Collection of the Best Text Editors in 2018" by Cody Arsenault @ KeyCDNکوئرامگ مجله‌ای تخصصی برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید توئیتر یا کانال تلگرام کوئرا را دنبال کنید. مریم مقدس برهان مریم مقدس برهان Mon, 06 May 2019 14:00:38 +0430 https://virgool.io/Quera-Mag/%DA%86%D8%B7%D9%88%D8%B1-%D8%AF%D8%B1-%D9%85%D8%B5%D8%A7%D8%AD%D8%A8%D9%87%D9%87%D8%A7%DB%8C-%D9%81%D9%86%DB%8C-%D9%87%D9%88%D8%B4%D9%85%D9%86%D8%AF%D8%A7%D9%86%D9%87-%D8%A8%D9%87-%D8%B3%D9%88%D8%A7%D9%84%D8%A7%D8%AA-%D8%AC%D9%88%D8%A7%D8%A8-%D8%AF%D9%87%DB%8C%D9%85-tjkzh0blutli سلما الشهاوی، فری‌کدکمپ — همه آدم‌ها دوست دارند آنقدر از این شرکت به آن شرکت بپرند تا بالاخره بهترین جایگاه شغلی ممکن را برای خودشان پیدا کنند. در حال حاضر، من به دنبال کار در شرکت‌هایی هستم که در فرهنگشان به حفظ تعادل بین کار و زندگی اهمیت می‌دهند. در همین پروسه، برای شرکتی رزومه فرستادم که به دنبال مهندس نرم‌افزار بود. افراد این شرکت از حرفه‌ای‌ترین افرادی بودند که به عمرم با من مصاحبه کرده بودند. مصاحبه‌گر از قبل خودش را کاملاً برای مصاحبه آماده کرده بود و در جلسه‌مان هم زمان کافی کنار گذاشت تا بتوانیم از همدیگر سوال بپرسیم.درباره رزومه‌نویسی این مطلب را در کوئرامگ بخوانید: راهنمای ساخت یک رزومه بی‌نظیر برای برنامه‌نویس‌ها و مهندس‌های نرم‌افزاردر این پست، می‌خواهم سوالاتی که این مصاحبه‌گر از من پرسید را با شما در میان بگذارم. این سوالات انواع مختلفی دارند؛ هم سوالات رفتاری هستند و هم سوالات فنی. در پایان مصاحبه، وقتی نوبت به من رسید من هم سوالاتی از طرف مقابلم پرسیدم که آنها را هم با شما درمیان می‌گذارم.چرا این مصاحبه را اینجا ثبت می‌کنم؟ چون معتقدم این مصاحبه، تجربه ارزشمندی بود که از مصاحبه رفتاری و فنی داشتم. شاید به بقیه مهندسان هم کمک کند تا درک بهتری در مورد نحوه پاسخ دادن به این نوع سوالات پیدا کنند!سوال‌های مصاحبه استخدام و علت آن‌هاسوال ۱ در مصاحبه استخدام: از خودت برایم بگو.هدف از پرسیدن این سوال، این است که با ارائه اطلاعاتی مختصر درباره خودتان، توجه کامل مصاحبه‌گر را به خود جلب کنید! بنابراین، باید از قبل تمرین کرده باشید که در جواب این سوال چه خواهید گفت. من دوست دارم قبل از مصاحبه، یک خلاصه مختصر و مفید در مورد خودم بنویسم و بعد با تمرین، سعی کنم این خلاصه را حداکثر در سی ثانیه (به روش معرفی آسانسوری یا همان Elevator Pitch) بیان کنم.جواب من: من مهندس نرم‌افزاری هستم که در رشته مهندسی مکانیک تحصیل کرده‌ام. علاقه خاصی به نوشتن کد تمیز، منظم و تست‌شده دارم. سابقه و تجربه کار با زبان‌های تابعی (Functional) و اسکریپتی را دارم.من اپلیکیشن‌های SaaS زیادی ساخته‌ام، از جمله در زمینه‌های احراز هویت (Authentication)، صدور مجوز (Authorization)، و پرداخت امن تجربه دارم. با کدنویسی در شغل قبلی‌ام آشنا شدم؛ آنجا اپلیکیشن‌هایی برای کمک به فرآیند طراحی می‌ساختم. حالا می‌خواهم مهارت‌هایم را به یک تیم خوب عرضه کنم که به دنبال عضوی جدید می‌گردد؛ عضوی که متعهد باشد و با عرصه‌های مختلف فناوری آشنایی داشته باشد.سوال ۲ در مصاحبه استخدام: موقعیتی را توصیف کن که وقت و منابع کافی در اختیار نداشتی، اما باید یک Feature کامل را در مدت زمان محدود تحویل می‌دادی.برای این نوع سوالات، شما باید این سه چیز را به شنونده توضیح بدهید: مسئله، راه‌حل، و عمل انجام شده. و باید این توضیح را در قالب یک داستان ارائه کنید!جواب من: قرار بود در یک اسپرینت دو هفته‌ای، نسخه دمو یک Feature را تحویل دهم. داستان کاربر (User Story) برای این Feature، دقیق مشخص نشده بود و تصمیم قطعی در مورد نحوه پیاده‌سازی آن گرفته نشده بود. علاوه بر این، مدیر محصول شرکت هم تازه استخدام شده بود و هیچ ایده‌ای در مورد این Feature نداشت. در عین حال، من هم وقت و منابع کافی برای شناسایی ورودی‌ها، خروجی‌ها و وابستگی‌ها در اختیار نداشتم.بنابراین تصمیم گرفتن با مدیر محصول و مدیر تیم جلسه‌ای مشترک تدارک ببینم تا بتوانیم با کمک هم، بارش فکری انجام دهیم و یک داستان کاربری ساده بسازیم که عملکرد مورد نظرمان را شبیه‌سازی کند. با این کار، ما به یک داستان کاربری دست پیدا کردیم که مورد تایید مدیر محصول‌مان بود. در نهایت، با مشخص شدن Feature، نوشتن و پیاده‌سازی کدهای پروژه را شروع کردم.سوال ۳ در مصاحبه استخدام: موقعیتی را برایم تعریف کن که در آن باید مشکلی را به مقام بالاتر از خودت انتقال می‌دادی.جواب من: قرار بود برای کدهای پروژه که یک توسعه‌دهنده دیگر نوشته بود، یک Unit Test بنویسم که Coverage بالاتری داشته باشد. باگی در کد بود که باعث می‌شد در یک بلوک بخصوص، Unit Test هیچ‌وقت موفقیت‌آمیز نباشد.من من فرآیند اشکال‌زدایی (Debugging) را شروع کردم تا ببینم باگ کجاست و درستش کنم. باگ را پیدا کردم؛ یک Query در دیتابیس بود که مشکل داشت. بررسی کردم تا ببینم مسئول این Feature چه کسی بوده، و ایمیل مفصلی در مورد مشکلی که در سر راه حل این مسئله وجود داشت، برایش فرستادم. او در پاسخ نوشت که بهتر است Unit Testها را طبق کد موجود که همچنان دارای باگ است بنویسم؛ زیرا همین فردا قرار بود دموی اسپرینت داشته باشیم و او مطمئن نبود که بشود مسئله را قبل از فردا صبح حل کرد.در این موقعیت، من تصمیم گرفتم قضیه را با مدیر تیم در میان بگذارم؛ زیرا Unit Test نوشتن برای یک باگ مثل این است که ماشین را عقب عقب برانی. مدیر تیم مسئله را بررسی کرد و از کسی که Feature را ساخته بود خواست تا کد پروژه را تصحیح کند.سوال ۴ در مصاحبه استخدام: از کجا مطمئن می‌شوی که دستوراتی که به شما داده شده دقیق و صحیح است؟جواب من: با بررسی دقیق و موشکافانه. به بعنوان مثال، وقتی که قرار است چیز جدیدی از یک متن راهنمای آموزشی یاد بگیرم، در هر قدم از کار خروجی را کنترل می‌کنم تا مطمئن شوم خروجی من عین همان چیزی شده که طبق راهنما قرار بوده باشد.سوال ۵ در مصاحبه استخدام: از کجا مطمئن می‌شوی که داده‌های تو با موفقیت در دیتابیس ذخیره شده است؟جواب من: راه‌های مختلفی برای این کار وجود دارد. می‌توانم با استفاده از یک تابع کمکی (Helper Method)، آن قسمت از داده را در دیتابیس چک کنم. اگر داده وجود داشت، Flag می‌زنم و مقدار آن را روی True تنظیم می‌کنم. اگر نبود، مقدار Flag را روی False می‌گذارم. شاید راه‌های دیگر هوشمندانه‌تر باشند، اما من دوست دارم با چشم خودم تایید نهایی را ببینم.سوال ۶ در مصاحبه استخدام: از کجا مطمئن می‌شوی که خروجی‌ کارت دقیقاً همان خروجی‌ای است که در داستان کاربر آمده؟جواب من: وقتی کاری به من محول می‌شود، یک فلوچارت می‌کشم و ورودی‌ها، خروجی‌ها و وابستگی‌ها را روی آن نشان می‌دهم. به این ترتیب اگر حواسم پرت چیزهای دیگر شود، می‌توانم با نگاه کردن به فلوچارتم سریعاً به موضوع اصلی برگردم. علاوه بر این، اگر یک جای کار گیر کنم، می‌توانم فلوچارتم را به افراد دیگری که با کدهای پروژه من آشنا نیستند هم نشان داده و با راحتی بیشتری از آنها کمک بگیرم.سوال ۷ در مصاحبه استخدام: به طور مفصل، موقعیتی را برایم تعریف کن که در آن تصمیم گرفتی که باید به سیاست‌های شرکت وفادار بمانی.جواب من: من شخصاً چنین موقعیتی را تجربه نکرده‌ام، اما یادم است که یکی از اعضای تیمم در چنین موقعیتی قرار گرفته بود. همکارم باید کدهای پروژه‌اش را با فراخواندن یک سیستم بیرونی (External) تست می‌کرد تا مطمئن شود که خروجی مطلوب را دریافت کرده است. برای این فراخوانی، لازم بود پروکسی‌ای را فعال کند که او را به سایت‌های بیرونی هدایت می‌کرد. فعال کردن این پروکسی مستلزم داشتن تاییدیه‌ (Certificate) بود. همکارم طبق رایج سیاست شرکت رفتار کرد و منتظر دریافت مجوز ماند.در اینجا مصاحبه‌گر از من پرسید که اگر جای همکارم بودم، در مدت انتظار برای گرفتن مجوز چه کار می‌کردم؟اگر این اتفاق برای من می‌افتاد، ترجیح می‌دادم در این مدت به بقیه در انجام کارهایشان کمک کنم؛ چون بدم می‌آید بیکار بنشینم.در اینجا مصاحبه‌گر از من تشکر کرد و گفت که اگر سوالی از او دارم، او آماده پاسخ دادن است. من معتقدم مصاحبه یک فرآیند دو طرفه است؛ بنابراین از قبل خودم را آماده کرده بودم و سوالاتی در چنته داشتم. این سوالات به من کمک می‌کردند تا فرهنگ شرکت را بهتر بفهمم و تصمیم بگیرم که آیا برای من جای مناسبی است یا خیر.سوالات خوبی که در مصاحبه استخدام می‌توانید بپرسیدحتماً سعی کنید که بر مبنای توضیحاتی که در آگهی شغلی داده شده، حداقل دو تا سوال در چنته داشته باشید. این سوالات باید عمیق و پرمعنی باشند و نشان دهند که شما به کار کردن در این جایگاه شغلی علاقه دارید.سوال ۱: شما با چه معیارهایی موفقیت‌آمیز بودن یا به شکست انجامیدن یک پروژه/اسپرینت را می‌سنجید؟در این سوال، من می‌خواستم ببینم که آنها در پیاده‌سازی Featureها چقدر خوب عمل می‌کنند. آیا فقط سعی می‌کنند اسپرینت را تمام کنند، یا اینکه کیفیت هم برایشان مهم است؟ سوال ۲: چطور مدت زمان انجام تسک‌ها را تخمین می‌زنید؟ و چه کسی این تخمین‌ها را می‌زند؟من می‌خواستم بدانم که آیا آنها توسعه‌دهنده‌ها را تحت فشار قرار می‌دهند و بدون اینکه از خودشان بپرسند به آنها کار محول می‌کنند؟ آیا داشتن چارچوب زمانی واقع‌گرایانه برایشان مهم است یا خیر؟ مدت زمان انجام تسک را می‌توان با ترکیبی از تئوری و تجربه تخمین زد: یعنی با استفاده از یک دنباله فیبوناچی ساده برای مشخص کردن حجم انجام کار، و با تخمین خود برنامه‌نویس‌ها.سوال ۳: چه کسی مسئول مستندسازی پروژه (Project Documentation) است؟ چند وقت یک بار این متون را به روز می‌کند؟در اینجا، می‌خواستم مطمئن شوم که اگر به این جایگاه شغلی برسم، لازم نیست منتظر بنشینم که یک نفر دیگر برای راهنمایی من بیاید و با پروژه آشنایم کند. اگر مستندسازی به خوبی انجام شده باشد، من یا هرکس دیگری می‌توانیم به راحتی و بی‌دردسر همه چیزهای لازم را متوجه شده و خودمان را به بقیه تیم برسانیم.سوال ۴: آیا شما ابزارهای آماری بخصوصی برای Coverage تست‌ها دارید؟هدف من از پرسیدن این سوال این بود که ببینم چقدر به کیفیت کد اهمیت می‌دهند. این ابزارها میزان Coverage موجود برای Test Caseها را نشان دهد.سوال ۵: آیا شما در شرکت‌تان مرتباً جلسات بحث و گفتگوی تخصصی برگزار می‌کنید؟ من کنجکاو بودم که بدانم آیا آنها به پیشرفت شغلی دولوپرهایشان اهمیت می‌دهند؟ آیا رشد مهارت‌های مهندسانشان برایشان مهم است؟سوال ۶: ساعات کاری شما تا چه حد منعطف است؟ آیا می‌توانید بعضی روزها از خانه کار کنید؟این سوال چیزهای زیادی را در مورد محیط کار آشکار می‌کند و دقیقاً به شما نشان می‌دهد که این شرکت از کدام نوع شرکت‌هاست. من اول چند تا سوال تخصصی پرسیدم تا خودم را به مصاحبه‌گر اثبات کنم، و بعد سراغ این سوال آمدم. اول احترامشان را جلب کنید، بعد از این نوع سوال‌های شخصی بپرسید!سوال ۷: از چه چیز این شرکت بیشتر از همه خوشتان می‌آید؟ و چه چیز تیمتان را بیشتر از همه دوست دارید؟من می‌خواستم ببینم که آیا مصاحبه‌گرم از کارش در این شرکت راضی است یا نه. این را به راحتی می‌توانید از لحن و تن صدای مصاحبه‌گر بفهمید: او یا با خوشحالی حرف خواهد زد و یا با لحن خنثی. هیجانی که در جوابش دارد، به شما نشان می‌دهد که آیا این شرکت استحقاق شما را دارد یا خیر.نکته‌های پایانی در مصاحبهنکته مهم در مصاحبه این است که تصویر خوبی از خودتان در ذهن مصاحبه‌گر به یادگار بگذارید. باید کاری کنید که او هرگز شما را از یاد نبرد. این گفتگو، فرصتی است برای اینکه چیزهای جدیدی از مصاحبه‌گرتان یاد بگیرید. سوالات هوشمندانه‌ بپرسید؛ سوال‌هایی بکنید که تصویر مثبتی از شما ایجاد کنند و به آنها نشان دهند که شما ارزش افزوده‌ای برای تیمشان خواهید بود. تا زمانی که می‌توانید، به سوال پرسیدن ادامه دهید. امیدوارم تجربه من بتواند به دولوپرهای دیگر در مصاحبه‌هایشان کمک کند.برای دیدن فرصت‌های شغلی برنامه‌نویسی می‌توانید به وبسایت کوئرا مراجعه کنید.ترجمه و ویرایش بر اساس:How answer — and ask — questions intelligently in tech interviews by Salma Elshahawy @ freeCodeCampکوئرامگ مجله‌ای تخصصی برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید توئیتر یا کانال تلگرام کوئرا را دنبال کنید. مریم مقدس برهان مریم مقدس برهان Sat, 04 May 2019 20:15:44 +0430 https://virgool.io/Quera-Mag/%D8%A8%D9%87%D8%AA%D8%B1%DB%8C%D9%86-%D8%B2%D8%A8%D8%A7%D9%86%D9%87%D8%A7%DB%8C-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%AC%D8%AF%DB%8C%D8%AF-%D8%A8%D8%B1%D8%A7%DB%8C-%DB%8C%D8%A7%D8%AF%DA%AF%DB%8C%D8%B1%DB%8C-%DA%A9%D8%AF%D8%A7%D9%85%D9%86%D8%AF-bmjopwrg0kly اگر می‌خواهید بازدهی بیشتری داشته باشید، یک زبان برنامه نویسی جدید یاد بگیرید.این توصیه‌ نوئل ولش (Noel Welsh)، یکی از بنیانگذاران شرکت مشاوره‌ای آندرسکور (Underscore) است. او اعتقاد دارد یادگرفتن زبان جدید، یکی از معدود راه‌های دولوپرها برای دست یافتن به موفقیت‌های بیشتر است.استدلال ولش که در کنفرانس کیوکان ۲۰۱۹ لندن (QCon) صورت می‌گرفت این بود: «زبان‌ها ابزارهای بسیار قدرتمندی هستند که به نظرم به آنها به قدر کافی بها نمی‌دهیم. تنها راه برای رسیدن به بازدهی کافی، این است که کدی ننویسیم و بهترین راه برای کم کردن کدنویسی غیرضروری، این است که زبان جدیدی یاد بگیریم.»به نظر ولش، کتابخانه‌های نرم‌افزاری با اینکه راه ساده‌ای برای کد ننوشتن جلوی پای آدم می‌گذارند، اما محدودیت‌هایی هم دارند. هر زبان برنامه نویسی، مجموعه گسترده‌ای از کتابخانه‌ها دارد که توسعه‌دهنده‌ها می‌توانند استفاده کنند. به این ترتیب، لازم نیست هربار که خواستیم یک کار تکراری انجام دهیم، چرخ را از نو اختراع کنیم. مثلاً برای ساختن اپلیکیشن‌های وب با Node.js جاوا اسکریپت، می‌شود از فریم ورک اکسپرس (Express) استفاده کرد.اما ولش می‌گوید که کتابخانه‌های نرم‌افزاری از یک جا به بعد دیگر جواب نمی‌دهند؛ زیرا کدی که این کتابخانه‌ها با آن ساخته شده‌اند، محدودشان می‌کند. ولی با یادگرفتن یک زبان جدید، می‌توان خیلی راه بیشتری رفت: می‌شود چند عملیات مختلف را در قالب دستورهای کمتر ترکیب کرد و از شر جزئیات پیچیده خلاص شد.ولش می‌گوید که «در نهایت، قدرتی که زبان‌ها به ما می‌دهند بیشتر از توانی است که کتابخانه‌ها در اختیارمان می‌گذارند؛ زیرا زبان میزبان، توانایی‌های کتابخانه را محدود می‌کند.مثلا اگر یک کتابخانه در C بنویسید، همیشه باید به مدیریت حافظه فکر کنید؛ راه دررویی ندارد». ولش اضافه می‌کند که «بعضی زبان‌های دیگر که سطح بالا (High-level) هستند، خودشان به طور خودکار تخصیص و آزادسازی حافظه را مدیریت می‌کنند. این مشکلی است که فقط با یک زبان می‌شود حلش کرد، و کتابخانه هیچ کمکی به رفع آن نمی‌کند.»البته واضح است که ویژگی‌های مثبت هر زبان را باید با توجه به امکاناتی که در دیزاین عرضه می‌کند، سبک سنگین کرد.برای مثال، در یک زبان سطح بالا مثل جاوا اسکریپت، توسعه‌دهنده برای مشخص کردن اینکه آیا متغیر عدد صحیح است یا ممیز شناور، به کامپایلر Just In Time متکی می‌شود؛ چرا که نمی‌تواند نوع متغیر را مشخص کند. یا در جاوا، ماشین مجازی جاوا (JVM؛ پلتفرمی که کد جاوا در آن اجرا می‌شود) «به شما اجازه نمی‌دهد که مستقیما کاری برای بُرداری‌ کردن (Vectorizing) کدها بکنید».اما وقت انتخاب زبان جدید، یکی از مهم‌ترین نکته‌ها این است که ببینید آن زبان با زبان‌هایی که شما یا شرکت‌تان استفاده می‌کنید، چقدر سازگاری دارد. ولش می‌گوید که «یک دلیل دیگر برای استفاده از زبان‌های جدید، این است که این زبان‌ها می‌گذارند به لگسی کدمان (legacy code) احترام بگذاریم، که سرمایه‌گذاری‌مان روی لگسی را حفظ کنیم. احترام به لگسی و حفظ آن یکی از انگیزه‌های اصلی شرکت ما بوده است.»با همین اهمیت لگاسی در ذهن، ولش فهرستی ارائه کرده است از زبان‌های منتخب‌ش که با زبان‌های موجود هماهنگی دارند، و برای دولوپرهایی که می‌خواهند زبان جدید یاد بگیرند گزینه‌های مناسبی هستند:اسکالا (Scala) برای توسعه‌دهنده‌های جاوااسکالا روی JVM اجرا می‌شود و به لطف این ماشین، با جاوا سازگار است. اسکالا ویژگی‌های مفید زبان‌های کاربردی را دارد و هدف از طراحی آن، این بوده که بتواند جایگزینی خلاصه‌تر و سرشار از امکانات برای جاوا باشد.اسکالا را اغلب زبانی می‌دانند که جایگاه‌های شغلی پردرآمد را با خود به همراه می‌آورد؛ حتی با اینکه میزان تقاضا برای آن کمتر از جاواست، و حتی با اینکه بیشتر برای تحلیل کلان‌داده (Big Data) به کار می‌رود.ولش می‌گوید که «وقتی اسکالا به میدان آمد، ما هنوز درگیر جاوا ۶ بودیم؛ در نتیجه همه اسکالا را روش خیلی بهتری برای دسترسی به JVM می‌دانستند. اگر اسکالا امروز وارد بازار می‌شد، شاید مثل آن روزها پرطرفدار نمی‌بود؛ زیرا جاوا خودش هم قدم در راه تغییر و نوآوری گذاشته است.»کاتلین (Kotlin) برای توسعه‌دهنده‌های جاوا در اندرویدراب فلچر (Rob Fletcher) که یکی از مهندسین ارشد نرم‌افزار در نت‌فلیکس است، کاتلین را این‌طور معرفی می‌کند: «کاتلین بعضی از بهترین قابلیت‌های دیگر زبان‌های را در کنار هم عرضه می‌کند و از آنجا که می‌توان آن را در JVM اجرا کرد، قابلیت تعامل‌پذیری (Interoperability) با جاوا را نیز به هم دارد.»محبوبیت این زبان متن‌باز و ایستا (Statically-typed) در سال ۲۰۱۷ حسابی بالا رفت، زیرا گوگل اعلام کرد که رسماً از کاتلین برای ساختن اپ‌های اندروید پشتیبانی می‌کند. قابل توجه است که در نظرسنجی برنامه‌نویس‌های Stack Overflow در سال گذشته، کاتلین دومین زبان محبوب برنامه‌نویس‌ها اعلام شده بود.جدا از اپ‌های اندروید، از کاتلین می‌توان برای ساختن اپلیکیشن‌های بک‌اند و سمت سرور هم استفاده کرد. اگر دوست دارید در مورد کاتلین بیشتر بدانید، سری به مجموعه‌ی تک‌ریپابلیک (TechRepublic) از منابع آنلاین کاتلین بزنید.سویفت (Swift) برای توسعه‌دهنده‌های آبجکتیو سیسویفت، جانشین انتخابی اپل برای آبجکتیو سی (Objective-C) در برنامه‌نویسی iOS و macOS است. این زبان، سینتکس مدرنی دارد که برنامه‌نویس‌ها را از قید سرسپردن به نیازهای مختلف C می‌رهاند، و در عین حال قابلیت همکاری با آبجکتیو سی را هم دارد.یادگرفتن سویفت آسان است و طوری طراحی شده که از نظر عملکرد، امنیت، و ایمنی نوع (type safety) مثل آبجکتیو سی باشد.راست (Rust) برای توسعه‌دهنده‌های Cراست طوری طراحی شده که عملکرد سریع C و ++C را داشته باشد، اما یک سری حفاظ (Safeguard) هم دارد که باعث می‌شوند در نتیجه سوءمدیریت حافظه، رفتارهای غیرمنتظره از نرم‌افزار سر نزند.راست کم‌کم دارد محبوب و محبوب‌تر می‌شود، و امروزه از آن برای ساختن نرم‌افزارهایی برای وب، کامپیوترهای توکار (Embedded)، خدمات توزیع‌شده (Distributed Services)، و خط فرمان (Command Line) استفاده می‌شود.ولش می‌گوید که «چیزی که در راست می‌بینیم، این است که با آن می‌توانید همه کارهایی که در C انجام می‌دادید و همه آن فراخوان‌های سیستمی (System call) را انجام دهید، اما خیلی خیلی بهتر از C.»تک‌ریپابلیک (TechRepublic) یک راهنما از منابع آنلاین برای یادگیری راست آماده کرده است که آن را می‌توانید اینجا ببینید.تایپ‌اسکریپت (TypeScript) برای توسعه‌دهنده‌های جاوا اسکریپتتایپ‌اسکریپت، یک اَبَرمجموعه (Superset) از جاوا اسکریپت است که دولوپرها می‌توانند با آن جاوا اسکریپت خالص بنویسند، و در عین حال با کمک قابلیت‌های جدیدی که دارد، برنامه‌های بزرگ‌تر و پیچیده‌تری بسازند.این زبان پشتیبانی از تایپ‌های ایستا را اضافه می‌کند و به کمک قابلیت‌های دیگرش، کار با کلاس‌ها و ماژول‌ها را راحت‌تر می‌سازد. از طرف دیگر، تایپ‌اسکریپت ابزارهای ساده‌تری هم برای وارسی و بازبینی ساختار کد عرضه می‌کند.تایپ‌اسکریپت به جاوا اسکریپت کامپایل می‌شود؛ بنابراین هرجایی که از جاوا اسکریپت استفاده شود، می‌توان از تایپ‌اسکریپت هم استفاده کرد: چه در اپلیکیشن وب برای اجرا در نرم‌افزار و چه کد بک‌اند در محیط Node.js.ترجمه‌ای از:Which are the best new programming languages for software developers to learn? by Nick Heath @ TechRepublicکوئرامگ مجله‌ای تخصصی برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید توئیتر یا کانال تلگرام کوئرا را دنبال کنید. مریم مقدس برهان مریم مقدس برهان Wed, 17 Apr 2019 14:53:07 +0430 https://virgool.io/Quera-Mag/%D9%87%D9%81%D8%AA-%D9%BE%D8%AF%DB%8C%D8%AF%D9%87-%D9%85%D9%87%D9%85-%D8%B1%D9%88%D8%A7%D9%86%D8%B4%D9%86%D8%A7%D8%B3%DB%8C-%D8%AF%D8%B1-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%DB%8C-fgxei7qppjip چرا یک UI خوب همیشه آنطور که انتظار داشتیم کار نمی‌کند؟ شاید چون UX بدی دارد! ¯\_(ツ)_/¯وقتی این عکس را دیدم اول فقط به نظرم کمی بامزه بود. بعد، گفتم یک آزمایش فکری روی آن انجام بدهم: چرا گربه‌ها اینطور رفتار کرده‌اند؟ صاحب آنها چطور می‌تواند این بلبشوی خنده‌دار را درست کند؟ این ظرف غذاها رابط کاربری (UI) ساده و تمیزی دارند، هر کسی که آنها را ببیند درجا می‌فهمد که اینها چه هستند. اما آیا تجربه کاربری‌‌شان‌ (UX) هم همین‌طور است؟مشکل: همه کاسه‌ها دقیقاً یک شکل هستند و همگی روی یک پایه چوبی یکسان قرار گرفته‌اند که سه سوراخ دقیقاً هم‌اندازه روی آن ایجاد شده است. وقتی گربه‌ها سر و کله‌شان پیدا شود، دقیقا از کجا باید بفهمند که سراغ کدام کاسه بروند؟یک راه حل ساده (i) این است که دو دیواره کوچک بین کاسه‌ها قرار دهیم تا نوعی اطاقک ایجاد شود، و به این ترتیب گربه‌ها ناخودآگاه احساس کنند که فضای مخصوص خودشان را دارند. راه حل بهتر (ii) این است که هر گربه را به سوی کاسه مخصوص خودش هدایت کنیم، که البته این کار مستلزم تمرین و تکرار است. ایده‌آل ترین راه (iii) این است که ببینیم هر گربه کدام کاسه را ترجیح می‌دهد، مطمئن شویم که هرکدام از گربه‌ها فقط به یکی از از کاسه ها علاقمند است، و بعد غذای مورد علاقه هر گربه را در ظرف مورد علاقه خودش قرار دهیم. راه حل (i)، طراحی مداخله‌ای یا Interventional Design نامیده می‌شود. دیوار و مانع به عمد و به شکل هدفمند کار گذاشته می‌شود تا هر کاربر بتواند به طور سوا و جدا از دیگران از محصول استفاده کند. این نوع طراحی را قبلاً هزار بار دیده‌ایم: دستگاه‌های خودپرداز، دستشویی، اتاقک تلفن، اتاق خواب، و غیره.راه حل (ii)، طراحی هدایتمند یا Directional Design نامیده می‌شود. اینجا از علایم و نشانه‌هایی برای جهت‌دهی استفاده می‌کنیم تا کاربران بتوانند بگردند و هدف مورد نظرشان را پیدا کنند؛ مثلا چیزهایی مثل تابلوهای ایستگاه مترو، نقشه شهر، و راه پله، کاربر را در یک سیستم پیچیده هدایت کرده و به مقصد می‌رسانند.راه حل (iii)، طراحی پیش‌نگر یا Proactive Design نامیده می‌شود. اینجا به جای اینکه همه آنچه داریم را به زور به خورد کاربر بدهیم، الگوی رفتاری کاربر را یاد می‌گیریم و از این اطلاعات برای خدمت به او استفاده می‌کنیم. برای همین است که اینستاگرام پست‌هایی شبیه به چیزهایی که لایک کرده‌اید را به شما نشان می‌دهد، یا گوگل مپ سعی دارد بر مبنای فعالیت‌های اخیر شما یک کافه هیجان‌انگیز برایتان پیدا کند.از شماره (i) تا (iii)، می‌توانیم ببینیم که راه‌حل‌ها رفته رفته شخصی‌تر و هوشمندانه‌تر می‌شوند. ما هوموساپینس‌ها حیوان‌های اجتماعی‌ و بااحساسی هستیم، نمی‌توانیم هیجاناتمان را از رفتارهایمان جدا کنیم. چیزی که محرک ما می‌شود، آن حس کامیابی بعد از رسیدن به موفقیت است و آن اعصاب‌خوردی‌هایی که زمان‌ شکست داریم. تصور کنید چه می‌شد اگر طراح‌ها و دیزاینر‌های محصولات تجاری به رفتارها، شناخت‌ها و تعاملات ما دقت نمی‌کردند؟ آن وقت ما هم داشتیم مثل این سه تا گربه زمین و زمان را به هم می‌زدیم!تجربه کاربری و روانشناسیطراحی UX، از قدیم رابطه دیرینه‌ای با روانشناسی اجتماعی، رفتاری و شناختی داشته است. همانطور که بالاتر گفتم، چیزی که انسان‌ها را به حرکت می‌اندازد انگیزه‌ و رقابت است. اگر چیزی که می‌خواهیم را ساده و مثل آب خوردن به دست بیاوریم، آن وقت راضی نیستیم. ما دوست داریم کار چالش داشته باشد، و از جایزه هم خوشمان می‌آید. هرم سلسله‌مراتبی نیازهای مازلو (Maslow) می‌گوید که درست بالای نیازهای پایه ما، نیازهای روحی و روانی‌مان نشسته‌اند. این نیازها هستند که باعث می‌شوند ما میل به چیزهای مختلف اشتیاق داشته باشیم، با هم همکاری کنیم، رقیب هم شویم، بسازیم، و نابود کنیم. (آشنایی بیشتر با هرم مازلو: منبع ۱، منبع ۲)دیزاینری که روان انسان را نمی‌فهمد، همانقدر موفق خواهد بود که یک معمار کاملا نا‌آشنا با فیزیک.- جو لیچ (Joe Leech)برای اینکه کنش و واکنش‌های روانی کاربر را بفهمیم، اول باید مشاهده کنیم. از شانس ما، روانشناسان از اوایل قرن نوزدهم مشغول بوده‌اند و مدام دارند آزمایش‌های فراوانی را در محیط‌های کنترل‌شده مختلف انجام می‌دهند. خیلی از پدیده‌های روانی رایجی که الان برایتان توضیح خواهم داد، قبلاً بررسی شده و پژوهش‌ها آنها را تایید کرده‌ است؛ تنها کاری که ما باید بکنیم این است که آنها را بفهمیم و ببینیم چطور می‌توان در طراحی تجربه کاربری از آنها استفاده کرد.تجربه کاربری ۱: ولی من فقط یه دکمه رو زدم! پدیده روانشناختی: شرطی‌سازی پاولفی (Pavlovian Conditioning)شرطی سازی پاولفی اگر مهم‌ترین آزمایش روانشناسی نباشد، حداقل یکی از مهم‌ترین‌های آنهاست. این اصطلاح به فرآیند یادگیری اشاره دارد که طی آن، یک محرک قدرتمند زیستی با یک محرک خنثی جفت می‌شود و آن را تبدیل به یک محرک قدرتمند می‌کند. به عبارت دیگر اگر عادت ‌کنیم که یک عمل بخصوص را طبق الگویی که یاد گرفته‌ایم انجام دهیم، در آن صورت هرجا که آن الگو را دوباره ببینیم، همان عمل را انجام خواهیم داد.در سیستم دیزاینی که خوب مستند شده باشد، همه دکمه‌های Call to Action اصلی باید یک رنگ برجسته و یکسان داشته باشند. هرجایی که لازم است کاربران عمل به خصوصی را انجام دهند، برای بالا بردن نرخ تبدیل (Conversion Rate) دیزاینرها دوست دارند یک دکمه فراخوان (CTA) هم قرار دهند. هرجا که قرار باشد مجموعه اعمالی با نتیجه مشابه انجام شود، دیزاینرها باید از همان دکمه استفاده کنند. بعد از اندکی استفاده، کاربرها رنگ و شکل دکمه دستشان می‌آید و فرض می‌کنند که هر دکمه‌ای به این رنگ و شکل به خصوص، همان کاری را خواهد کرد که دکمه‌های مشابه قبل از آن کرده‌اند. اما اگر از این الگوی یکسان پیروی نکنیم چه اتفاقی می‌افتد؟آن وقت شاهد یک الگوی سیاه (Dark Pattern) هستیم. این طراحی نفرت‌انگیز، کاربران را گول می‌زند و باعث می‌شود آنها کارهایی بکنند که نمی‌خواستند بکنند. (درباره الگوی سیاه و برخی نمونه‌های آن بیشتر بخوانید.) خنده‌دار است که چطور ذهن ما به این سادگی به دام می‌افتد، اما حتی باهوش‌ترین‌ آدم‌ها هم ممکن است فریبش را بخورند. دیزاینرها! از این قدرت سوءاستفاده نکنید؛ وگرنه خودتان یا محصولتان به همان بلایی دچار خواهید شد که در سال ۲۰۱۵ با ۱۳ میلیون دلار جریمه بر سر لینکدین آمد.تجربه کاربری ۲: عجیبه... اما حس خوبی بهم میده!پدیده روانشناختی: اثر دارونما (Placebo Effect)این اصطلاح روانشناسی به زمانی اشاره دارد که یک بیمار، ماده‌ای بدون هیچگونه اثر درمانی دریافت می‌کند، اما به نظرش می‌آید که این ماده برایش مفید بوده و حالش دارد بهتر می‌شود. بعضی پژوهش‌ها هیچ شواهدی دال بر اثرگذار بودن اثر دارونما پیدا نکرده‌‌اند و درمان بیمار به این شکل، معمولاً کاری ریاکارانه و گمراه‌کننده تلقی می‌شود. فارغ از همه بحث و جدل‌هایی که در مورد اثر دارونما هست، این پدیده روانشناختی در بسیاری از وقایع روزمره خودش را به شکل عملی نشان می‌دهد. حدس و گمان‌های بسیاری در مورد اثر دارونما می‌زنند؛ مثلا اینکه شاید بعضی وقت‌ها صرفاً لازم داریم کسی به ما کمی اطمینان بدهد. یا شاید دوست داریم حرفی که خودمان به آن اعتقاد داریم را یک نفر دیگر هم به خودمان بگوید. کل قضیه به این برمی‌گردد که اثر دارونما باعث می‌شود افراد احساس کنند شرایط را تحت کنترل دارند؛ حتی اگر در واقعیت هیچ کنترلی روی اوضاع نداشته باشند.یکی از نمادین‌ترین مثال‌ها برای این پدیده، انیمیشن Pull-to-Refresh است. هرکسی که حداقل سه روز گوشی هوشمند دستش گرفته باشد می‌داند این انیمیشن چطور کار می‌کند؛ اما فکر می‌کنید چند نفر می‌دانند که این در واقع یک اثر دارونما است؟ کاربران انتظار دارند که وقتی صفحه را به پایین کشیدند، صفحه رفرش شود؛ اما آنها هیچ کنترلی روی اینکه لود کردن صفحه چقدر طول میکشد ندارند. بنابراین دیزاینرها به جای اینکه صفحه را خالی بگذارند، انیمیشن Pull-to-Refresh را می‌سازند تا به کاربر اطمینان بدهند که لود کردن واقعا دارد اتفاق می‌افتد، و صفحه جدید به زودی نشان داده خواهد شد. کاربر قضیه را اینطور می‌بیند که «من این کار را کردم، من باعث شدم صفحه ریلود شود، من بودم که مثل یک قهرمان صفحه را پایین کشید؛ من شرایط را تحت کنترل دارم!» اما واقعیت این است که کاربر هرچقدر محکم و پرانرژی هم که صفحه را پایین بکشد، آن صفحه فقط زمانی رفرش خواهد شد که لود کردنش تمام شود. اما انیمیشن حواس کاربر را پرت می‌کند و باعث می‌شود او به محدودیت فنی‌ای که برای پردازش جریان انبوه داده در Back-end وجود دارد، توجه نکند. بله، یک کمی شبیه سر را شیره مالیدن است؛ اما خب ضرری به کسی نمی‌رساند. ?تجربه کاربری ۳: تروخدا گریه نکن، من رو هم به گریه میندازی!پدیده روانشناختی: اثر آفتاب‌پرستاین اصطلاح روانشناسی به این مسئله اشاره دارد که آدم‌ها وقتی در نزدیکی کسی هستند، ناخودآگاه رفتار و هیجان آن فرد را تقلید می‌کنند. تا حالا شده که دوستتان یک کلمه خاص را به زبان بیاورد، و بعد شما همان کلمه را در خطاب به خودش دوباره تکرار کنید؟این تقلید در واقع راهی است برای نشان دادن ارتباط و صمیمیت‌مان با دیگران؛ بخصوص به افراد نزدیکی مثل خانواده و دوست‌ها. ما ناگزیر این کار را انجام می‌دهیم تا به آنها نشان دهیم که حواسمان به آنها هست؛ که حسشان را می‌فهمیم.در تجربه‌های فردی با محصولات، تک‌تک تعامل‌ها صمیمانه و آنی هستند. ما روبات نیستیم؛ ولی از دستگاه‌ها استفاده می‌کنیم احساس داریم و هیجان‌های مختلف را تجربه می‌کنیم. اگر یک راهنمای بصری در محصول وجود داشته باشد، می‌تواند هیجانات ما را دقیقاً همانطور که مد نظر سازندگان محصول بوده تغییر دهد. برای همین است که از سال گذشته، کلمه طراحی هیجانی (Emotional Design) اینقدر بین دیزاینرها باب شده است؛ زیرا دیزاینرها مشتاق‌اند تا با استفاده از شباهت‌های روانشناسی، بین کاربر و محصول ارتباط مناسب را برقرار کنند.نمونه ۱ از طراحی هیجانی:دوئولینگو (Duolingo) خوب می‌داند چطور با احساسات کاربرانش بازی کند!نمونه ۲ از طراحی هیجانی:وقتی کلیک کردن بر روی دکمه جستجو، باعث خوشحالی سازندگان اپلیکیشن می‌شود!تجربه کاربری ۴: اما... آخه خیلی خوشگه...پدیده روانشناختی: اثر زیبایی‌شناختی-استفاده‌پذیری (Aesthetic-Usability Effect)این اصطلاح روانشناسی می‌گوید که برخی افراد اعتقاد دارند که اگر محصولی طراحی زیبایی داشت، لابد استفاده کردن از آن هم ساده‌تر (Intuitive) است. معمولاً این عقیده را کسانی دارند که از دانش فنی بالایی در این مورد برخوردار نیستند. این کاربران وقتی در استفاده از محصولی با طراحی جذاب به مشکل بخورند، خودشان را سرزنش می‌کنند و نه مشکل در کارکردهای محصول را. شاید برایتان پیش آمده باشد که عکس قشنگی توجهتان را به خود جلب کرده، در محصولی از رنگ مورد علاقه‌تان زیاد استفاده شده، یا اینکه انیمیشن‌های بامزه اپلکیشنی حسابی دلتان را برده است.در همه این حالت‌ها، واکنش‌های هیجانی مثبت شما به این طراحی باعث می‌شود تعاملاتتان با آن محصول بیشتر از پیش تقویت شود، باگ‌های استفاده‌پذیری به چشمتان نیاید، و در مقابل مشکلات محصول صبر و تحمل بیشتری از خود نشان دهید. این قضیه دقیقاً شبیه آن موقع است که با آدم خوشتیپی سر قرار می‌روید و با خود می‌گویید «وای، چه پسر خوشتیپی! لابد آدم خیلی خوبی است. اگر با هم کنار نیاییم، آن وقت حتماً مشکل از من است. من آدم مسخره‌ای هستم.»منبع: https://dribbble.com/shots/6123802--Meditation-App-Automated-Hack-23بیایید از این عکس به عنوان مثال استفاده کنیم. در سمت چپ صفحه، سه آیکون را می‌بینید که به خاطر کمرنگ بودن، واضح دیده نمی‌شوند؛ بنابراین اگر کسی کوررنگی داشته باشد یا درکش از کنتراست خیلی قوی نباشد، دسترسی‌پذیری (Accessibility) محصول برای او کاهش قابل توجهی پیدا می‌کند؛ علاوه بر این، اینجا هیچ توضیحی وجود ندارد که هر آیکون دقیقاً چه کار می‌کند! به نظر من واقعا کار اشتباهی است که استفاده‌پذیری ( Usability) را فدا کنی، فقط برای اینکه فضای منفی غیرضروری داشته باشی. در سمت راست صفحه، یک تب عمودی قابل اسکرول کردن می‌بینیم که طراحی آن در موبایل احتمالاً یکی از بدترین ایده‌های ممکن در جهان است؛ زیرا نه تنها اجرا کردن آن تقریباً غیر ممکن است، بلکه کیفیت UX اسکرول‌ کردن به طور کلی در موبایل را هم کاهش می‌دهد (دلیلی هست که هیچ کس در طراحی اپ آن را به کار نبرده؛ چون جواب نمی‌دهد!)اما برای شما پشیزی اهمیت ندارد که من الان چه گفتم، مگر نه؟ لابد الآن داشتید با خودتان می‌گفتید که «آخه... قیافه‌اش که قشنگ و تمیزه...» بنابراین دفعه بعد که اسکرین‌شاتی در Dribbble دیدید و آنقدر دلتان را برد که UX به کلی از یادتان رفت، نگران نباشید. تقصیر شما نیست. نمی‌شود جلوی این عکس‌العمل را گرفت.تجربه کاربری ۵: تو همان بچه عجیب‌غریب بیست سال پیش هستی، مگه نه؟پدیده روانشناختی: اثر وان رستورف (Von Restorff Effect)این پدیده که به نام اثر جداسازی (Isolation Effect) هم شناخته می‌شود، می‌گوید که اگر یک شیء در بین مجموعه‌ای از اشیا متفاوت باشد و تفاوتش به چشم بیاید، احتمال بیشتری دارد که افراد بتوانند بعدها آن را به یاد بیاورند. در نظریه‌های زیادی اشاره شده است که توانایی یادآوری ادراکی افراد، اغلب با ویژگی‌های بافتاری (Contextual) چیزها ارتباط دارد.حافظه با گروه‌بندی و طبقه‌بندی کار می‌کند. انسان‌ها خاطراتشان را برمبنای شکل، اندازه، وزن، رنگ، بو، یا صدای چیزها طبقه‌بندی می‌کنند. اگر چیزی خاص و منحصر به فرد باشد، آنوقت افراد می‌توانند در یک تکلیف یادآوری آزاد (Free-recall Task)، آن را به یاد بیاورند؛ زیرا خاص بودن آن چیز باعث شده که یک طبقه جداگانه فقط برای آن ساخته شود.یک نمونه خیلی خوب از این اثر، طراحی نوتیفیکیشن‌هاست. ما هرروز به صفحه home screen گوشی‌مان نگاه می‌کنیم، و به ندرت ممکن است که تغییری در آن ببینیم؛ مگر اینکه نوتیفیکیشنی دریافت کنیم. فرقی ندارد که آن نوتیفیکیشن صدای بیپ بدهد یا تصویری باشد، در هر دو حالت توجه ما را به خود جلب می‌کند.تصویر نوتیفیکیشن‌ها از Peter Centofanteتجربه کاربری ۶: چرا همه همیشه بچه وسط را یادشان می‌رود؟پدیده روانشناختی: اثر دنباله-جایگاه (Serial-Position Effect)این پدیده نشان می‌دهد که اگر یک دنباله و سری از موارد وجود داشته باشد، افراد بیشتر موردهای اول و آخر لیست را به یاد می‌آورند و موردهای وسط لیست غالباً فراموش می‌شود.اگر می‌خواهید یک لیست طراحی کنید، بهتر است که موارد کم‌اهمیت‌تر را وسط لیست بگذارید. البته بعضی وقت‌ها سخت می‌‌شود تصمیم گرفت که کدام مورد به بقیه برتری دارد. راه حل خود من برای این مسئله، این است که ترافیک سایت را بررسی می‌کنم. این کار همیشه می‌تواند نشانم بدهد که بازدید از کدام محتواها از همه بیشتر و کدام‌ها از همه کمتر بوده. به این ترتیب می‌فهمم که دقیقاً چه چیزهایی را باید وسط لیست گذاشت.تجربه کاربری ۷: هرچقدر بیشتر نگاهش می‌کنم، بامزه‌تر می‌شود!پدیده روانشناختی: اثر مواجهه‌ی صرف (Mere-Exposure Effect)این پدیده روانشناختی می‌گوید که افراد چیزهایی را که برایشان آشناست، ترجیح می‌دهند. همه‌مان این اتفاق را تجربه کرده‌ایم؛ مثلا وقتی کسی را مرتباً می‌بینیم، بیشتر ممکن است که آن فرد به نظرمان جذاب و دوست‌داشتنی بیاید. از بخت بد کاربران، این کل چیزی است که متخصصان سئو لازم داشتند بشنوند. به خاطر همین پدیده است که تبلیغات بنری در سطح وب وجود دارند، چون آژانس‌های تبلیغاتی معتقدند که صرفاً با فرو کردن تبلیغاتشان در چشم کاربر می‌توانند رد و خاطره‌ای از محصول را در ذهن او باقی بگذارند.در طراحی UX، ایجاد کردن این حس آشنایی برای کاربر حیاتی است.دیزاینرهای باهوش یک استراتژی جالب کشف کرده‌اند: آنها می‌آیند و دکمه «بعدی» را در گوشه بالا سمت چپ صفحه‌های آموزش استفاده از برنامه (Onboarding Screens) می‌گذارند، و وقتی کاربر به صفحه Home Screen اصلی برنامه می‌رسد، آنجا هم در گوشه بالا سمت چپ یک آیکون وجود دارد. این آیکون می‌تواند عکس پروفایل کاربر، تنظیمات، نوتیفیکیشن، یا هر نوع دکمه CTA باشد که می‌خواهید کاربر آن را فشار دهد. کار خیلی کوچکی است، اما نرخ تبدیل اپلیکیشن شما را زیر و رو می‌کند. کاربران قبلاً وجود دکمه در آن گوشه را تجربه کرده‌اند؛ بنابراین بخاطر سیالی شناختی‌شان استفاده دوباره از دکمه‌ای در آن نقطه خیلی برایشان راحت‌تر است.جمع‌بندیاین مطلب فقط قطره‌ای بود از دریای طراحی روانشناختی UX. با تحقیقاتی که در مورد طراحی تجربه کاربری کرده‌ام، به این نتیجه رسیدم که فقط از طریق مشاهده کردن و فهمیدن رفتارها و هیجانات کاربران نهایی است که می‌توانم یک محصول واقعاً کاربردی بسازم. با این همه، ما دیزاینرها باید در مورد اینکه چطور بر هیجانات کاربران تاثیر می‌گذاریم، احتیاط به خرج بدهیم. اگر خوب تحقیق نکنیم و موقع اجرا دقت کافی نداشته باشیم، حتی اگر نیت‌مان خوب بوده باشد هم ممکن است بدترین تاثیرات را بر کاربر بگذاریم. یادتان باشد، مهم‌ترین اصل این است که همیشه باید سعی کنید تا خود را به جای کاربرانتان بگذارید و ببینید او قرار است چه حسی از کار شما پیدا کند.ترجمه بر اساس:7 Principal Psychological Phenomena in UX Design by Carlos Han @ Prototyprکوئرامگ مجله‌ای تخصصی برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید توئیتر یا کانال تلگرام کوئرا را دنبال کنید. مریم مقدس برهان مریم مقدس برهان Tue, 09 Apr 2019 15:12:31 +0430 https://virgool.io/Quera-Mag/%DA%86%D8%B7%D9%88%D8%B1-%D8%A8%D8%A7-%D8%AA%D9%88%D8%AC%D9%87-%D8%A8%D9%87-%D8%AC%D8%B2%D8%A6%DB%8C%D8%A7%D8%AA-%D8%B4%D8%B1%D9%84%D9%88%DA%A9-%D9%87%D9%88%D9%84%D9%85%D8%B2-%D8%A8%D8%A7%DA%AF%DB%8C%D8%A7%D8%A8%DB%8C-%D8%B4%D9%88%DB%8C%D9%85-vxjfhv0mugaq اگر بخواهید چیزی را پیدا کنید، در قدم اول باید بدانید که آن چیز دقیقاً چیست. درست مثل کارآگاه‌ها، متخصصان Testing هم وقتی دنبال باگ می‌گردند، یک سری تحقیق و تفحصات انجام می‌دهند. هر نوع باگی ویژگی‌های منحصر به فرد خودش را دارد. در تیم‌های توسعه نرم‌افزار، یک Software Tester باید همه این ویژگی‌های خاص باگ‌ها را بداند تا بتواند «مجرم» را شناسایی کند!بیایید با چند نوع از باگ‌ها شروع کنیم که معمولاً شناسایی کردنشان سخت است اما رواج بسیار زیادی دارند:باگ کارکردی (Functional Bug)این باگ را وقتی می‌توانیم پیدا کنیم که همه کارکردهای سیستم را بررسی کرده، و مطمئن شویم که هرکدام همان کاری را می‌کنند که باید بکنند. اگر یک Function کار عجیب و غریبی بکند که در لیست کارهای مورد نیاز نبوده، این یک باگ محسوب می‌شود. مثال بزنم؛ فرض کنید دکمه‌ای در اپلیکیشن هست که قرار بوده پنجره A را باز کند؛ اما در عوض، این دکمه یا پنجره B را باز می‌کند یا اینکه کلا هیچ چیزی را باز نمی‌کند. این یک باگ کارکردی است.اگر نیازمندی‌های کارکردی (Functional Requirements) وجود نداشته باشد، پیدا کردن این باگ سخت‌تر می‌شود. در چنین حالتی داشتن تجربه قبلی کار با یک نرم‌افزار مشابه، خیلی به کار می‌آید. یک راهکار دیگر برای پیدا کردن این باگ‌ها هم این است که تست‌های اکتشافی (Exploratory Testing) انجام دهید.باگ رابط کاربری (User Interface Bug)اگر همه موکاپ‌های صفحات نرم‌افزار را داشته باشید، پیدا کردن باگ‌های UI کار راحتی است. کل کاری که باید بکنید این است که مکان، شکل، رنگ و دیگر ویژگی‌های عناصر بصری را با موکاپ مقایسه کنید.یک راه دیگر هم این است که همراه با موکاپ‌ها یا به جای آنها، یک سری دستورالعمل‌های دیزاین تحویل بگیرید. این دستورالعمل‌ها معمولاً استایل‌ها و عناصر دیگر را در حالت‌های مختلفشان توصیف می‌کنند؛ مثلا اینکه رنگ لینک در حالت اولیه، وقتی ماوس رویش هست، و بعد از کلیک کردن چه تفاوتی می‌کند.اگر هیچگونه مستندسازی (Documentation) برای دیزاین انجام نشده، نگران نباشید. فقط با بررسی نرم‌افزار هم می‌شود بیشتر باگ‌های UI را پیدا کرد. دنبال خرابی Layout، بلوک‌ها (Blocks) یا المان‌های (Elements) روی هم افتاده، متن خارج از بلوک، و هر عنصر دیگری باشید که سر جایش نیست یا کلا ناپدید شده است. در حین پروسه باگ‌یابی، به زودی متوجه خواهید شد که اغلب باگ‌های UI وقت گشتن به دنبال باگ‌های کارکردی خودشان را نشان می‌دهند.باگ‌های محلی‌سازی (Localization Bug)پیدا کردن باگ‌های محلی‌سازی فقط وقتی لازم می‌شود که نرم‌افزارتان چند زبان مختلف را پشتیبانی کند، و/یا زمانی که قرار باشد افرادی از منطقه‌های زمانی (time zone) مختلف از آن استفاده کنند. اولین چیزی که باید چک کنید، این است که آیا زبان‌های مختلف دارند به یک اندازه درست کار می‌کنند؟ متن همه المان‌های سیستم باید ترجمه شود. مستند‌سازی مفصل اینجا به کار می‌آید، اما اگر آن را نداشته باشید هم می‌توانید باگ‌ها را شکار کنید. باید بعد از اینکه زبان پیش‌فرض را تغییر دادید، همه المان‌ها را بررسی کنید. اگر بعضی از آنها ترجمه نشده‌ بودند، یک باگ دارید. در این مرحله از کار ممکن است بعضی باگ‌های UI را هم پیدا کنید؛ چون کلمات و عبارت‌های یکسان در زبان‌های مختلف ممکن است طولانی‌تر یا کوتاه‌تر باشند. در نتیجه متن ممکن است از بلوک بیرون بزند و یا اینکه کلا آن را خراب کند.بسته به این که نرم‌افزارتان از چه نوعی است، ممکن است لازم باشد نحوه نمایش داده شدن زمان را هم چک کنید. به ترتیب نمایش داده شدن سال-ماه-روز و ساعت-دقیقه دقت کنید، چرا که ممکن است کشورهای مختلف در این ترتیب‌ها با هم فرق داشته باشند. بررسی کنید که نمایشگر ساعت با منطقه زمانی کشور مورد نظر تطابق داشته باشد. اگر قرار است امکان تغییر واحد پولی متناسب با کشور کاربر هم وجود داشته باشد، باید این امکان را هم چک کنید تا ببینید درست کار می‌کند یا نه.باگ کاربردپذیری (Usability Bug)اگر استفاده از نرم‌افزار راحت نباشد، احتمالا هیچ کس از آن خوشش نمی‌آید. چنین نرم‌‌افزاری هرگز معروف نخواهد شد. بنابراین باید به باگ‌های کاربردپذیری توجه ویژه‌ای داشته باشید.اگر پیدا کردن یک Function (مثلا دکمه ثبت نام) برای کاربر خیلی طول بکشد، این قطعاً یک باگ کاربردپذیری است. رنگ‌های نامناسب هم باگ محسوب می‌شوند؛ مثلا وقتی که به خاطر زیادی روشن بودن رنگ بک‌گراند، کاربر نتواند متن را به خوبی ببیند، چشم‌هایش درد بگیرد، و نتواند به مدت طولانی از اپلیکیشن استفاده کند. یک باگ دیگر هم که خیلی هم پیش می‌آید، دکمه‌هایی هستند که کارکردشان برای کاربر دقیقا مشخص نیست: مثلا هیچ راهنمایی برایشان نشان داده نمی‌شود، تصویر آیکون معلوم نیست به چه چیزی اشاره دارد، و یا اینکه اسم آیکون کارکردش را دقیق بیان نمی‌کند.در ادامه لیست، می‌خواهیم با باگ‌هایی آشنا شویم که شاید در اینترنت یا کتاب‌ها توضیح درست و حسابی در مورد آنها پیدا نشود؛ اما این به این معنی نیست که وجود ندارند:باگ ادغامی (Integration Bug)ادغام Componentهای نرم‌افزار فقط منحصر به سیستم‌های پیچیده نیست، بلکه در وبسایتی که خوب طراحی شده باشد هم انجام می‌شود. اگر اطلاعات به خوبی از یک Component به دیگری منتقل نشود، این یک باگ است. مثال‌های زیادی برای چنین مسئله‌ای می‌شود زد. مثلا یک وبسایت را تصور کنید که در آن صفحه A، اطلاعات B را دارد که قرار بوده به صفحه C منقل شوند. اگر اطلاعات B با اطلاعات موجود در صفحه C یکی نباشد، این یک باگ ادغامی است.حالا یک سیستم بزرگ ERP (برنامه‌ریزی منابع سازمانی) را در نظر بگیرید که در آن Componentهای بسیاری با هم ادغام شده‌اند. فرض کنید در این سیستم یک قرارداد می‌سازیم و پروفایل فردی که قرارداد به او مربوط است را انتخاب می‌کنیم. اگر پروفایلی در سیستم وجود دارد ولی به طور خودکار وارد قرارداد نمی‌شود، این یک باگ است.باگ آپدیت سیستم (System Update Bug)به‌روزرسانی سیستم، بخش جدایی‌ناپذیر نرم‌افزارهای مدرن است. در این آپدیت‌ها معمولا چند Function جدید ارائه شده و چند باگ مهم رفع می‌شود، اما نکته اینجاست که ممکن است در خود فرآیند آپدیت هم باگی وجود داشته باشد. پیدا کردن این باگ‌ها خیلی سخت است، اما رایج‌ترین آنها معمولاً باعث می‌شوند کاربر همه تنظیماتی که انجام داده را از دست بدهد و یا اینکه کلا از حساب کاربری‌اش بیرون انداخته شود.باگ صوتی (Audio Bug)هر اپلیکیشنی صدا ندارد، اما آن اپلیکیشن‌هایی که نوتیفیکیشن می‌دهند یا صدا یکی از Functionهای اصلی‌شان است باید کاملاً از نظر صوتی چک شوند. اولین چیزی که باید بررسی کنید این است که آیا اصلاً برنامه صدایی تولید می‌کند؟ اگر جواب مثبت است، باید مطمئن شوید که کیفیت صدا خوب است و وقفه یا خللی در وسط صداها پیش نمی‌آید. چک کردن شدت صدا (volume) را هم از یاد نبرید. حتماً بررسی کنید که آیا شدت صدای پیش‌فرض همانی است که قرار بوده باشد، و اینکه آیا بالا و پایین کردن شدت صدا آن را واقعا تغییر می‌دهد یا خیر.باگ‌های Texture و Objectهای سه بعدیاین باگ در بازی‌های نقش‌آفرینی آنلاین چندنفره (MMORPG) و سایر بازی‌های سه‌بعدی خیلی شایع است. بعضی وقت‌ها این نوع باگ‌ها را به سختی می‌شود پیدا کرد، زیرا ممکن است از نظر بصری قابل تشخیص نباشند. برای شکار آنها باید اول تفاوت بین باگ Texture و باگ Objectهای سه بعدی را بدانیم. بیایید اول از باگ‌های سه بعدی شروع کنیم. مثلاً ممکن است شخصیت بازی بعد از انجام یک کار بخصوص یا رفتن به یک مکان خاص، ناگهان ناپدید شود. این اتفاق در نتیجه ناپایداری‌ها و Aliasهای ضعیف Objectها در این وضعیت/مکان بخصوص اتفاق می‌افتد. وجود textureهای روی هم ممکن است باعث شود که از این باگ غافل شوید. یک مثال دیگر برای این باگ، حالتی است که شخصیت بازی در یک جایی گیر افتاده، و Object‌هایی که سد راهش شده‌اند نمی‌گذارند از آنجا خارج شود.از طرفی Texture صرفاً عکسی است که روی Object گذاشته می‌شود. اگر یک مانع نامرئی باعث شود که شخصیت بازی نتواند جلو برود، این یعنی این که آن Object دارای Texture نیست. بعضی وقت‌ها هم Texture هست، اما با Object مطابقت نمی‌کند.باگ محتوا (Content Bug)معمولاً این تیم کپی‌رایتینگ یا ویراستاری هستند که محتوای سایت را چک می‌کنند، زیرا آنها می‌دانند که دقیقاً چه مطلبی آنجا گذاشته شده است. با این حال، بعضی باگ‌های محتوا واضح‌تر از این هستند که نادیده گرفته شوند؛ مثلاً اشتباه شدن عنوان یا اسم شرکت. فقدان عکس یا لینک‌های اشتباه هم باگ محتوا محسوب می‌شوند.در نهایت، بیایید با چند باگ نرم‌افزاری آشنا شویم که شاید مثل باگ‌های قبلی واضح و مشخص نباشند:هایزن‌باگ (Heisenbug)اسم این باگ از هایزن‌برگ (Heisenberg) می‌آید؛ یعنی‌کاشف اصل عدم قطعیت در مکانیک کوانتوم. هایزن‌باگ به آن خطاهایی اشاره دارد که مثلا وقت اجرا شدن نرم‌افزار در IDE دیده می‌شوند، اما وقتی برنامه با Debugger اجرا شود اثری از آنها نیست.تصویر از: simonb.comبورباگ (Bohrbug)نام این باگ از مدل اتمی بور (Bohr) گرفته شده است. برخلاف هایزن‌باگ، بورباگ هر بار که یک شرایط بخصوصی پیش بیاید خودش را نشان می‌دهد. اما به عقب برگشتن در سیر وقایع و پیدا کردن عامل ایجاد کننده آن تقریباً غیرممکن است.مندل‌باگ (Mandelbug)این باگ به نام بنوا مندلبرو (Benoit Mandelbrot) نام‌گذاری شده است که پیشرفت‌های عظیمی در حیطه مطالعه فراکتال‌ها ایجاد کرد. مندل‌باگ خطایی است با دلیلی عمیقاً پیچیده و مبهم، آنقدر که این دلیل به نظر غیر منطقی و غیر قابل توضیح می‌رسد (دقیقاً «به نظر می‌رسد»). این باگ ممکن است به خاطر واکنش کند سیستم اتفاق بیفتد. یک نمونه از مندل‌باگ، خطایی هست که رخ داده، اما شما خیلی بعدتر از رخ دادنش از آن باخبر می‌شوید و برای همین پیدا کردن دلیل مشکل برایتان خیلی سخت می‌شود.شرودین‌باگ (Schrödinbug)اسم این باگ از آزمایش معروف گربه شرودینگر (Schrödinger) گرفته شده است. تصور کنید که برنامه‌ای دارید و این برنامه به خوبی دارد کار می‌کند. شما تصمیم می‌گیرید نگاهی به کد برنامه بیندازید. وقتی این کار را می‌کنید می‌بینید کد برنامه طوری است که قاعدتاً اصلاً نباید کار می‌کرده. از همان لحظه‌ای که این را می‌فهمید، برنامه از کار می‌افتد! در نهایت وقتی بلاخره کد را اصلاح کردید، برنامه دوباره شروع به کار می‌کند. به نظر غیرممکن می‌رسد، اما واقعیت این است که در عالم واقع چنین باگ‌هایی خیلی زیاد پیش می‌آیند.ترجمه‌ای از:How to Become the Sherlock Holmes of Bug Searching: Concentration on the Details By Andrew Smith @ DZoneکوئرامگ مجله‌ای تخصصی برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید توئیتر یا کانال تلگرام کوئرا را دنبال کنید. مریم مقدس برهان مریم مقدس برهان Mon, 11 Mar 2019 12:28:48 +0330 https://virgool.io/Quera-Mag/%D8%B3%D9%87-%D8%B1%D8%A7%D9%87-%D8%B4%DA%AF%D9%81%D8%AA-%D8%A7%D9%86%DA%AF%DB%8C%D8%B2-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%B3%D8%A7%D8%AF%D9%87-%DA%A9%D8%AF-%D8%B2%D8%AF%D9%86-xw6nqo8shxc9 زندگی خیلی ساده است، اما ما اصرار داریم پیچیده‌اش کنیم.نوشتن کدهای ساده، واقعا ساده است. اما ما با آماده کردن کدها برای آینده (Future-ready)، کار خودمان را پیچیده می‌کنیم!وقتی که یاد بگیریم توهم آمادگی برای آینده را کنار بگذاریم، هم کدهایمان تمیزتر و ساده‌تر می‌شود و هم اعتبارمان به عنوان یک برنامه‌نویس خوب، پیش بقیه بالا می‌رود.اجازه بدهید توضیح بدهم.آن زمان که در دوران اوج برنامه‌نویسی‌ام بودم، یک اصل وجود داشت که در هر موقعیتی به من یاد داده می‌شد:«هیچوقت یک کد را دوبار ننویس.»«باید کدت را بازسازی کنی. باید بخاطر نفع همگانی، کاری کنی که کدت قابل استفاده مجدد باشد. کدت را شبیه جعبه سیاه (black box) کن تا هر برنامه‌نویس دیگری که روی کره زمین هست، بتواند از آن استفاده کند. برنامه‌نویس‌های خوب، کدهای عالی‌شان را تا ابد برای دیگران به یادگار می‌گذارند.»تا اینجای کار که مشکلی نیست.البته به جز یک مشکل خیلی خیلی بزرگ: اینکه کدهایی که من می‌نوشتم، کم‌کم تبدیل به یک کپه زشت و هولناک از حرف‌ها و عددهای بی‌معنی می‌شد که فهمیدن و تفسیرشان غیر ممکن بود. بهداشت کدنویسی (code hygiene) من کلاً از بین رفت، و روزها و ماه‌ها را فقط صرف این می‌کردم که آفریده‌های شیطانی‌ام را اصلاح کنم و زندگی نویی به آنها ببخشم.برنامه‌نویسی کار سختی است. وقتی برنامه‌ای می‌نویسی، چیزی بین یک تا یک گازیلیون خط کد خواهی داشت و قرار است اشتباهاتی هم بکنی. شاید اشتباهاتت کوچک باشند و شاید هم بزرگ؛ اما در هر اندازه‌ای که باشند، پیدا کردن و رفع‌شان حتماً زمان می‌برد. وقتی در آن گرداب خطرناک درماندگی داری به سرعت غرق می‌شوی، بعضی وقت‌ها نیاز داری که یک نفر دستت را بگیرد و بیرونت بکشد. اما بعضی وقت‌ها هم... تنها چیزی که لازم داری یک اردک زرد حمام است.اولین بار دین پارکر (Deane Parker) بود که در پست زیبایش با عنوان «چطور سخنرانی خوبی بکنیم»، مفهوم اردک حمام را مطرح کرد. در این پست، او توضیح می‌دهد که چطور می‌شود با تمرین کردن سخنرانی با صدای بلند، آن را بهتر کرد. این ایده که از اردک حمام به عنوان شنونده سخنرانی‌مان استفاده کنیم حرف جدیدی نیست؛ اما جذابیتش در اینجاست که هم راحت می‌شود عملی‌اش کرد و هم موثر است. اصلی‌ترین مزیت استفاده از اردک حمام به عنوان شنونده، این است که اردک زرد صبور است و قضاوت هم نمی‌کند. از همه بهتر، با کمک او دیگر لازم نیست وقت شخص دیگری را بگیری. جادویی در بلند بلند توضیح دادن مشکلات هست (حتی به چیزی بی‌جان مثل اردک حمام) که کمک می‌کند راه حل مسئله را پیدا کنی. وقتی که شروع می‌کنید به مرور کردن کد و توضیح دادن خط به خط آن به اردک حمام، یکدفعه می‌بینید که دارید یک دید بیرونی به موقعیت پیدا می‌کنید. آنجاست که خودتان را مجبور به ارزیابی خودتان می‌کنید، و در حال و هوای آن لحظه، درکی عینی و بی‌طرف از همه کدهایی که نوشته‌اید به دست می‌آورید.و بعد، دیر یا زود بلاخره به آن لحظه «آها!» می‌رسید. جواب معما یک دفعه به ذهنتان می‌رسد. و تقریبا هر دفعه به خودتان می‌گویید: «وا! من که اینو می‌دونستم!»در اینجا چندتا از چیزهایی را آورده‌ام که در جلسه‌هایم با اردک حمام، در مورد بهتر کد زدن یاد گرفتم:لازم نیست هر دفعهComponent قابل استفاده مجدد بسازیدبعضی‌ها متعقدند که آدم باید همیشه componentهایش را تا می‌شود قابل استفاده مجدد کند؛ زیرا با این کار مجبور می‌شود با همه مشکلات مربوط به کیفیت کدش روبرو شود و در نهایت نرم‌افزار بهتری تولید خواهد کرد. اگر تنها هدف شما این باشد که بهترین نرم‌افزار دنیا را بسازید، چنین عقیده‌ای خیلی خوب است. اما متاسفانه هیچ کس برای ساختن بهترین نرم‌افزار جهان به شما پول نمی‌دهد.نه؛ چیزی که شما به خاطرش پول می‌گیرید این است که با رعایت بودجه و زمان اختصاص داده شده، نرم‌افزاری بنویسید که در حد لازم، کیفیت داشته باشد. اگر بیخودی برای آب‌طلا‌کاری کردن کدتان وقت بگذارید، شاید احساس کنید خیلی خفن هستید، اما عملا کار کاملا بی‌فایده‌ای انجام داده‌اید. باید برای خودتان مرزی مشخص کنید و بدانید که این محصول را دقیقاً تا چه حد خوب باید بسازید. پا از این مرز فراتر نگذارید. اگر بگذارید، درست کردن محصول هیچ‌وقت تمام نخواهد شد.قرار نیست لازمش داشته باشید«قرار نیست لازمش داشته باشید» (YouArentGonnaNeedIt یا YAGNI) اصلی در برنامه‌نویسی Extreme است که می‌گوید: «هر چیزی را زمانی بسازید که واقعاً لازمش دارید، نه وقتی که پیش‌بینی می‌کنید لازمش داشته باشید.»حتی اگر کامل کامل کامل مطمئن بودید که یک Feature را بعداً لازم خواهید داشت، الآن آن را نسازید.دو دلیل برای اجرای اصل YAGNI وجود دارد: در وقت صرفه‌جویی می‌کنید، چون دیگر کدی که لازم نیست را نمی‌نویسید.کدتان بهتر می‌شود، زیرا آن را با «حدس‌»ها آلوده نمی‌کنید؛ حدس‌هایی که بعداً قرار است معلوم شود که اشتباه بوده‌اند، اما باز هم کسی حذفشان نخواهد کرد.ساده‌ترین حالتی که ممکن است جواب بدهد را بسازیدبرنامه‌نویسی Extreme دو قانون طلایی برای نوشتن کد ساده دارد:یک ویژگی‌ جدید را در ساده‌ترین حالتی که ممکن است جواب بدهد، بسازید. یک عالمه فراساختار (Super structure) حیرت‌‌آور درست نکنید، کارهای تجملاتی و قشنگ‌قشنگ انجام ندهید. فقط کدی را بسازید که کار می‌کند. کدی بسازید که آزمایش‌های واحد (Unit Tests) برای Feature جدید (و همه Featureها، مثل همیشه) را با موفقیت پشت سر بگذارد.این یکی بخش حیاتی قانون است: سیستم را طوری بازسازی کنید که در عین داشتن همه Featureها، ساده‌ترین کد ممکن باشد. با اجرا کردن قانون یکبار و فقط یکبار (OnceAndOnlyOnce) و دیگر قانون‌های کیفیت کد، سیستم را به تمیزترین حالت ممکنش تبدیل کنید.یادتان باشد که قرار نیست سریع‌ترین راه را پیدا کنیم، بلکه قرار است به ساده‌ترین نتیجه برسیم. بنابراین، در قدم اول متد فعلی را به چند قسمت تقسیم می‌کنیم. با این کار Test Caseهای موجود همچنان اجرا می‌شوند. در قدم بعدی، سراغ یکی از متدهای کوچک‌تر می‌رویم و آن را طوری تغییر می‌دهیم (البته به شکل ساده) که Test Case بعدی انجام شود. همین روند را برای همه متدها ادامه می‌دهیم.دفعه بعد که گیر کرده بودید، سراغ اردک حمام برویدرفع باگ‌ها، حل مشکلات و پیدا کردن راه حل برای مسئله‌های بغرنج، از بخش‌های اساسی برنامه‌نویسی هستند. بنابراین یاد گرفتن تکنیک‌هایی برای به سلامت بیرون آمدن از بین باگ‌ها و bindها، همانقدر مهم است که یادگرفتن همه سینتکس‌ها. و وقتی گیر کردید و هیچ چیز کار نمی‌کرد، سراغ اردک حمام بروید.پس بروید و اردک حمام خودتان را پیدا کنید؛ چه همان اردک زردپوش کلاسیک باشد و چه اردکی که لباس دزد دریایی تنش است. اردکی را انتخاب کنید که با آن راحتید و با ویژگی‌های شخصیتی‌تان سازگار است.شروع کنید؛ با او حرف بزنید، سوال بپرسید، مشکلاتتان را بلند برایش توضیح دهید، گره‌های توی ذهنتان را باز کنید و یک کد عالی تحویل بدهید.همانطور که کریس پاین (Chris Pine) به خوبی گفته است:«در برنامه‌نویسی مهم نیست که چه چیزی بلدید، مهم این است که جواب کدام مسئله‌ را می‌توانید پیدا کنید.»ترجمه‌ای از:3 Amazing Ways To Write Simple Code, The Startupکوئرامگ مجله‌ای تخصصی برای توسعه‌دهندگان است که هر هفته با مطلب‌هایی در زمینه تکنولوژی، رشد فردی و آینده برنامه‌نویسی به‌روزرسانی می‌شود. برای اطلاع از آخرین مطلب‌های ما، می‌توانید توئیتر یا کانال تلگرام کوئرا را دنبال کنید. مریم مقدس برهان مریم مقدس برهان Sat, 02 Mar 2019 18:16:51 +0330