تنظیم موقعیت جالب در وب به کمک jQuery

امروز به حسب کاری که بر روی یک پروژه انجام می‌دادم به دنبال یک پلاگین خوب jQuery برای نمایش tooltip ها بودم که به qTip2 رسیدم.

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

برای مشخص کردن محل نمایش tooltip ابتدا باید مفهوم مرزهای مختلف یک المنت را مطابق شکل زیر بررسی کنید.

شکل بالا محل‌های مختلف یک المنت را در وب نشان می‌دهد

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

$('.selector').qtip({
    content: 'I am positioned using corner values!',
    position: {
        my: 'top left',  // Position my top left...
        at: 'bottom right', // at the bottom right of...
        target: $('.selector') // my target
    }
}); 

 کد بالا مشخص می‌کند که پلاگین qTip2 برای المنت با کلاس selector اجرا شود و در بخش position سمت چپ بالای tooltip را از پایین راست مرز المنت selector آغاز می‌کند.

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

درس‌هایی از استیو جابز و اپل برای کسب و کار نرم‌افزار قسمت پنجم: آنچه که مهم است محصول است

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

محصول مهمترین است

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


چند سال بعد از زمانی که جابز پیکسار را خرید اولین محصول فیلم بلند آن‌ها (مشترک با دیزنی) داستان اسباب بازی 1 بود.
نتیجه؟ پیکسار که در آستانه نابودی بود، به اوج رسید. شرایط قراردادش با دیزنی را تغییر داد.
سهامش را به عموم عرضه و بعد جابز آن را تبدیل به یک برند شاخص در حوزه انیمیشن کرد. 

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

"... به محض ورود -با شلوار کوتاه، کفش کتانی و یک یقه اسکی سیاه- جلسه را به سبک پر انرژی خودش شروع کرد. گفت: «خب، به من بگویید مشکل کجاست؟» پچ پچ‌ها بالا گرفت ولی او خیلی زود جمعش کرد: «محصولات!» و سپس سوال دوم را پرسید: «خب، محصولات چه مشکلی دارند؟» چند تلاش نافرجام برای پاسخ دادن به این پرسش شکل گرفت تا اینکه باز خودش وسط پرید و پاسخ صحیح را داد، آن هم با فریاد: «محصولات افتضاحند! هیچ جذابیتی ندارند!»"

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

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

در همین رابطه بخوانید:

چطور بفهمیم که با نرم‌افزارمان یک مشکل واقعی را حل کرده‌ایم؟

مزیت رقابتی در صنعت نرم‌افزار

پی‌نوشت: گرچه به روزرسانی آرایه برای 22 شهریور ماه برنامه‌ریزی شده بود اما وارد شدن یک پروژه دیگر در میان برنامه توسعه سایت باعث شد تا اعمال تغییرات تا امروز انجام نشود. امروز تغییراتی در برنامه سایت داده شد، از جمله امکان مشاهده نوشته‌های یک موضوع (دسته بندی خاص) و فید rss دسته‌بندی‌ها، جستجو، پیشنهاد مطالب مشابه و ...
این تغییرات البته هنوز کامل نشدند و ممکن است مشکلاتی داشته باشند که در روزهای آتی برطرف خواهند شد.

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

تست جوئل قسمت هفتم: لیست مشخصات نرم‌افزار

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

تست هفتم جوئل: آیا دارای لیست مشخصات هستید؟

هر محصول صنعتی دارای مشخصات (specifications) است، نرم‌افزار هم از این قاعده مستثنی نیست. هر کد نرم‌افزاری باید بر مبنای یک سند مشخصات یا به اختصار spec تولید شود.

جوئل در این مورد می‌گوید: "نوشتن لیست مشخصات (specifications) درست مثل استفاده از نخ دندان است:‌ همه قبول دارند كه كار خوبی است ولی هیچ كس حوصله‌اش را ندارد."


در فصل اول سریال فرار از زندان،اگر مایکل اسکوفیلد تونست از زندان فرار کنه، فقط به خاطر هوشش نبود،
لیست مشخصات بخش‌های مختلف زندان رو هم داشت!

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

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

توجه کنید که سند مشخصات نرم‌افزار واقعاً باید یک سند مکتوب باشد و صحبت درباره مشخصات نرم‌افزار و آنچه که شما درباره نرم‌افزاری که دارید می‌سازید در ذهن دارید spec محسوب نمی‌شود!

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

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

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

جوئل اسپالسکی هم مثالی درباره عواقب عدم توجه به این مساله می‌زند: "به نظر می‌رسد كه مشكل Netscape نیز همین بوده - چهار نسخه اول آن قدر شلم شوربا شد كه مدیریت به طرز احمقانه‌ای تصمیم گرفت همه كد آن را دور بياندازد و از صفر شروع كند. سر Mozilla هم دوباره همین اشتباه را مرتكب شدند،كه محصول آن هیولایی خارج از كنترل است كه چند سال طول كشیده تا فقط به مرحله آلفا برسد."

حالا که درباره اهمیت لیست مشخصات صحبت کردیم، در نوشته‌های دیگری به این موضوع خواهیم پرداخت که لیست مشخصات چیست و چطوری باید یک سند spec درست کنیم؟

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

تست جوئل قسمت ششم: برنامه‌ریزی و تخمین زمان اجرا بر اساس شواهد

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

تست ششم جوئل: آیا برنامه زمانبندی‌تان به روز است؟

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

یکی از مهمترین دلایلی که جوئل برای داشتن یک برنامه زمانبندی به‌ روز اشاره می‌کند بحث جلوگیری از بیماری featuritis است. بیماری که طراحان و برنامه‌نویسان دچار آن می‌شوند و می‌خواهند به یک سیستم پیچیده امکانات بیشتری را بدون برنامه‌ریزی لازم اضافه کنند. درباره این بیماری در نوشته دیگری مفصل صحبت خواهم کرد، فعلا در پرانتز از تجربه شخصی‌ام در این مورد می‌گویم که محصولی ایجاد کرده بودیم که بر اساس تنظیماتش alert‌های شرطی را به صورت آنی ارسال می‌کرد، برای اینکه از قابلیت‌های این محصول در یک محصول دیگر برای ارسال alert‌ها استفاده کنیم، قابلیت ارسال بر اساس یک زمان‌بندی مشخص (روزانه، هفتگی، ماهیانه) به محصول اضافه شد. نتیجه؟ محصول فوق‌العاده پیچیده شد، دیباگ آن عملاً به یک کابوس تبدیل شد و توسعه آن غیرممکن! برای رهایی از مشکلاتی که اضافه کردن این قابلیت خاص بدون بررسی لازم و پیش‌بینی عواقب آن ایجاد کرده بود، در نسخه بعدی محصول، عملاً قابلیت ارسال بر اساس زمان‌بندی حذف شد!

چطور یک برنامه ‌ریزی موفق داشته باشیم؟

جوئل در نوشته دیگری به موضوع برنامه‌ریزی می‌پردازد. روش معرفی شده در این نوشته که Painless Software Schedules نام دارد دیگر قدیمی شده و جوئل Evidence Based Scheduling را پیشنهاد می‌کند.

قبل از صحبت درباره برنامه‌ریزی جوئل به دلایل اینکه برنامه‌نویسان از برنامه‌ریزی تولید نرم‌افزار فرار می‌کند می‌پردازد. مهمترین دلیلی که ذکر می‌شود این است که: "هیچ کس باور نمی‌کند که برنامه‌ریزی انجام شده واقع‌بینانه باشد!

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

 

Evidence Based Scheduling چطور کار می‌کند؟ 

برای اینکه یک برنامه‌ریزی موفق با استفاده از روش EBS داشته باشید باید کارهای زیر را انجام دهید:

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

2- زمان صرف شده را ثبت و بررسی کنید: همه افراد در تخمین زمان اجرای کارها مثل هم نیستند، بعضی دقیق‌تر تخمین می‌زنند و بعضی هم با اختلاف زیاد. نکته مهم این است که زمان تخمین زده شده و زمان واقعی اجرای کارها را ثبت و بر اساس آن نموداری به شکل زیر برای هر برنامه‌نویس آماده کنید.

 

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

حالت ایده‌آل velocity عدد یک است، یعنی زمان تخمین زده شده و زمان واقعی با هم برابر باشند. در این حالت برنامه نویسی که خوب می‌تواند تخمین بزند، در نمودارش اعداد 1 را برای velocity خواهد داشت. بر حسب میزان تجربه و دقت در تخمین، ممکن است velocity بیشتر یا کمتر از 1 باشد، در نهایت velocity به شما نمایی از میزان دقت در برنامه‌ریزی برای هر شخص در تیم می‌دهد.

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

 

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

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

درباره روش EBS در مطلب جداگانه‌ای بیشتر صحبت خواهم کرد.

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

ساده کد بنویسید

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


کد ساده چیست؟

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


همیشه برای حل مسائل راه ساده‌تری هم هست!

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

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

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

نوشتن کد ساده چه مزایایی دارد؟

نوشتن یک کد ساده حداقل مزایای زیر رو داره:

  • راحت خونده می‌شه. برنامه‌نویس جدیدی که به تیم وارد می‌شه خیلی راحت ازش سر در میاره حتی بدون خوندن کامنت‌های شما!
  • راحت تست می‌شه یا راحت می‌شه براش تست نوشت.
  • راحت می‌شه از کد ساده نگهداری کرد.
  • توسعه کد ساده خیلی راحت‌تر از کد پیچیده است و احتمال اینکه تصمیم بگیرید به دلیل پیچیدگی بیش از حد باید کل کد رو دور بریزید و از اول بنویسید کم می‌شه.
چطور بفهمیم کد ساده نوشتیم؟
 
به اعضای کمپین ضد if بپیوندید! هر چه استفاده از if در کد شما بیشتر باشه، یعنی کد شما پیچیده‌تر هست و سر در آوردن ازش (به خصوص وقتی که خیلی if تو در تو دارید) مشکل.
 
نکته دیگه رعایت استانداردهای نام‌گذاری هست. از خودتون استاندارد generate نکنید. این راهنما از مایکروسافت می‌تونه خیلی کمک کنه. البته استفاده از ابزارهایی مثل Resharper که توی کد به شما پیشنهاداتی ارائه می‌کنند هم می‌تونه مفید باشه.
 
به سایز توابعی که می‌نویسد نگاه کنید. وقتی یک تابع نوشتید که بیش از 300 خط کد دارد، وقتی تمام منطق صفحه را در یک تابع Page_Load نوشتید، وقتی هر کدام از event handler‌های شما خودش یک برنامه است یعنی کد پیچیده‌ای نوشتید که 2 ماه دیگر خودتان هم از آن سر در نمی‌آورید.
 
کدهای تکراری را حذف کنید، در کدهای پیچیده کارهای تکراری باعث شلوغی بی دلیل کد می‌شود. به یاد داشته باشید که یکی از روش‌های درهم‌ و مبهم کردن کد (به منظور اینکه با reflector ها دیگران کد شما را نبینند) اضافه کردن کد بی‌معنی و بیهوده به کد اصلی است. بنابراین همیشه برای داشتن یک کد ساده و قابل فهم، کدهای اضافی را به صورت کتابخانه یا کلاس مجزا درآورده و آن‌ها را قابل استفاده مجدد (reusable) کنید.
 
شما درباره نوشتن کد ساده چه ایده‌ای دارید؟ در مورد کد ساده در نوشته دیگری که درباره اصل KISS هست بیشتر صحبت خواهم کرد.
به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

ویندوز یا لینوکس، مساله این نیست!

دیروز مطلبی در سایت .NET Tips دیدم تحت عنوان "PHP سریع‌تر از ASP.NET! واقعیت یا افسانهنویسنده مطلب اشاراتی به بعضی دلایل فنی از جمله تفاوت PHP و ASP.NET از نظر نوع زبان (مفسری یا کامپایلی بودن) و تعدادی benchmark داشته و در نهایت نتیجه گرفته است که سریع‌تر بودن PHP درست نیست.

در این نوشته به یک موضوع اساسی در حوزه فناوری اطلاعات می‌پردازم: طرفداری. این طرفداری می‌تواند مثلاً در حوزه سیستم عامل باشد (دعوای طرفداران لینوکس و ویندوز) یا موبایل و سیستم عامل موبایل (دعوای طرفداران اندروید و iOS) یا تکنولوژی‌های وب (دعوای طرفداران PHP‌ و ASP.NET) و ...


شما یادتون نمیاد! یکی از معروف‌ترین wallpaper های زمان ما که به دعوای لینوکسی‌ها و ویندوزی‌ها اشاره داشت

مقایسه درست و مقایسه غلط

یک واقعیت این است که در بسیاری از حوزه‌های فناوری نمی‌توان یک مقایسه کامل و بی‌نقص انجام داد. مثلاً همین مساله سرعت PHP‌ و ASP.NET را در نظر بگیرید. هر دو این فناوری‌ها برای تولید صفحات پویا استفاده می‌شوند، بنابراین مقایسه سرعت برای تولید یک کد html ساده (در حد echo کردن یا معادل دات نتی آن Response.Write) چیزی را معلوم نمی‌کند و مهم نیست!

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

و همه این‌ها به کنار، من به عنوان یک برنامه‌نویس ASP.NET می‌توانم برنامه‌ام را به شکلی بنویسم که با بدترین performance و کندترین شکل ممکن اجرا شود! یعنی الگوهای استفاده شده در تولید نرم‌افزار و مهارت برنامه‌نویس و روش اجرا هم واقعاً در مقایسه تاثیرگذار است: فرض کنید به دو برنامه‌نویس که یکی PHP‌ کار است و دیگری ASP.NET کار بگویید برنامه‌ای بسازد که در یک آرایه مشخص (که برای هر دو برنامه یکسان است) به دنبال یک عنصر خاص بگردد. یکی بهینه‌ترین (و خفن‌ترین) الگوریتم جستجو را پیاده‌‌سازی کند و دیگری جستجوی خطی را پیاده کند. معلوم است که نتیجه چه خواهد بود.

مقایسه گوشی‌ها را در پلتفرم‌های مختلف در نظر بگیرید. یک بازی مشخص را روی آیفون و مثلاً گلکسی اس 4 نصب می‌کنیم و بعد نتیجه می‌گیریم که عملکرد کدام بهتر است غافل از اینکه گرچه بازی یک بازی است اما به دلیل تفاوتی ذاتی پلتفرم‌های iOS و اندروید عملاً دو بار نوشته شده است (یا از یک پلتفرم به دیگری پورت شده) و این یعنی مبنای مقایسه ما درست نیست.

بنابراین در دعواهای طرفداری همیشه این موضوع را در نظر بگیرید که آیا مقایسه انجام شده کاملاً قابل اطمینان است یا خیر؟

فناوری، یک ابزار در دست شماست. نه بیشتر نه کمتر

اگر در رشته کامپیوتر درس خوانده باشید، لابد دعواهای دانشجویی بر سر انتخاب سیستم عامل و زبان برنامه‌نویسی را از ترم‌های اول دانشگاه به یاد دارید!

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

به عبارت بهتر همه این فناوری‌ها فقط ابزار هستند و نباید آن‌ها را از اندازه ابزار بزرگتر دید. 

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

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

من رفقایی داشتم که با تعصب خاصی معتقد بودند دلفی خیلی قوی‌تر از vb است. شاید درست می‌گفتند ولی آخرش بورلند (به آن شکلی که می‌شناختیم) تمام شد! و آن طرفداران متعصب ماندند و ابزاری که دیگر مثل قبل نبود و در برابر دات نت زانو زده بود. 

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

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

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی