بایگانی دسته: تکنولوژی

داکر چیست؟

لوگوی داکر

مدتی است داکر (Docker) در فضای IT تبدیل به یک موضوع داغ تکنولوژیک شده است. در نتیجه، بسیاری به دنبال یادگیری و استفاده از این ابزار برآمده اند. در این پست سعی می کنم خلاصه ای از ماهیت داکر و مسائلی که این ابزار سعی در حل آنها دارد را بیاورم.

داکر متشکل از یک ابزار خط فرمان و یک سرویس (Daemon) است که:

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

در ادامه هر یک از این موارد را با جزئیات بیشتر مورد بررسی قرار می دهیم.

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

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

یکی دیگر از امکانات داکر مجازی سازی در سطح سیستم عامل است. اما این عبارت به چه معناست و چه مزایایی دارد؟ در گذشته نه چندان دور، یکی از روش های ایزوله سازی نرم افزارها استفاده از ماشین های مجازی بود (البته ماشین مجازی کاربردهای دیگری هم دارند که برای ساده تر شدن درک مفاهیم از آنها صرفنظر می کنیم). در این رویکرد یک ماشین میزبان (Host) وجود دارد که سیستم عاملی مشخص دارد برای مثال لینوکس. به علاوه، روی سیستم میزبان یک نرم افزار مجازی سازی نصب می شود (مانند VMWare یا سایر ابزارهای مشابه). حال باید با استفاده از ابزار مجازی سازی ماشین های مجازی ایجاد شوند. هر ماشین مجازی باید یک سیستم عامل و در نهایت نرم افزاری که می خواهیم ایزوله شود را داشته باشد. خلاصه این موارد را می توانید در تصویر زیر مشاهده کنید:

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

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

یکی دیگر از امکانات داکر فراهم آوردن یک مخزن برای دانلود و نصب نرم افزارها است. این مخزن به آدرس https://hub.docker.com در دسترس است (هرچند به علت تحریم ها در حال حاضر این سایت به صورت مستقیم قابل استفاده نیست. اما می توانید با ابزارهای دور زدن تحریم یا اندیس های جایگزین از این امکان استفاده کنید).

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

در نوشتن این پست سعی شده موارد تا حد امکان بدون ذکر جزئیات فنی مطرح شوند تا مطلب برای همه مخاطبان قابل مطالعه باشد. اگر به یادگیری بیشتر در این باره علاقه دارید، پیشنهاد می کنم کتاب Docker In Action نوشته Jeff Nickoloff رو مطالعه کنید. در نهایت امیدوارم موارد مطرح شده مورد استفاده قرار بگیرد.

برای آگاهی از پست های بعدی می توانید در کانال تلگرام وبلاگ عضو شوید.
برای عضویت در کانال وبلاگ اینجا کلیک کنید

چاپ چهارم کتاب برنامه نویسی با پایتون

امروز چاپ چهارم کتاب برنامه نویسی با پایتون به بازار ارائه شد. نام دقیق این اثر «برنامه نویسی با پایتون ۳» است. چاپ اول این کتاب (همون طور که در این پست) توضیح دادم سال ۱۳۹۳ به بازار ارائه شد و «برنامه نویسی با پایتون» نام داشت. طی چاپ های متوالی و با به روز شدن کتاب نام ویرایش دوم و چاپ سومش به «برنامه نویسی با پایتون ۳» تغییر کرد و چاپ چهارمش هم، با همین نام به بازار ارائه شده است. امیدوارم مفید واقع بشه. برای سفارش آنلاین کتاب می توانید به وب سایت نشر دانشگاهی کیان مراجعه کنید.

مطالعه رایگان یک فصل از کتاب برنامه نویسی با پایتون ۳

 

برای آگاهی از پست های بعدی می توانید در کانال تلگرام وبلاگ عضو شوید.
برای عضویت در کانال وبلاگ اینجا کلیک کنید

هدف تفکر طراحی (Design Thinking)

مدتی قبل در دورهمی IDF تهران ارائه ای درباره تفکر طراحی (Design Thinking) داشتم. اسلایدها و فایل صوتی این ارائه را می توانید به صورت رایگان از آدرس زیر دانلود کنید (همین جا و داخل پرانتز از همه دوستان و عزیزانی که این دورهمی رو برگزار کردند تشکر می کنم):

دانلود اسلایدهای ارائه دانلود فایل صوتی ارائه

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

اگر تاریخچه پدید آمدن تفکر طراحی را مطالعه کنید، حتما با مقاله مهم و ارزشمند هورست ریتل (Horst Rittel) با عنوان Dilemmas in a general theory of planning مواجه خواهید شد. ریتل در این مقاله به بررسی مسائل خاصی، که خود آنها را مسائل بدخیم (Wicked Problems) می نامد پرداخته است (ممکن است بدخیم معادل فارسی مناسبی برای کلمه Wicked نباشد، اما در حال حاضر معادل بهتری برای آن نیافته ام. برخی، آن را به بدسرشت هم ترجمه کرده اند. اما، بد سرشت ترجمه مناسبی برای این واژه نیست. به خصوص وقتی با کلمه مسئله همراه می شود). مسائل بدخیم، مسائلی پیچیده (پیچیده به معنای تشکیل شده از اجزا) و چندبعدی هستند. از نظر ریتل این مسائل بیشتر در تقابل با جامعه رخ می دهند. به قول ریتل: «مشکلات اجتماعی هیچ گاه به صورت قطعی حل نمی شوند بلکه بارها و بارها فیصله می یابند». فیصله را به عنوان ترجمه Resolve به کار برده ام. وقتی مسئله ای حل می شود عموما همه طرفین از حل آن راضی هستند. اما، وقتی دعوا یا اختلافی فیصله می یابد یا اصطلاحا Resolve می شود همه طرفین رضایت ندارند!

ریتل علت حل نشدن مشکلات و مسائل اجتماعی را در ذات این مسائل می داند. او این مسائل را بدخیم (در مقابل مسائل خوش خیم یا به اصطلاح Tame، مثل معادله های ریاضی که راه حلی مشخص دارند)  می نامد و ۱۰ ویژگی برای این مسائل بر می شمارد که در ادامه به بررسی این ویژگی ها می پردازیم. هدف تفکر طراحی ارائه فرآیندی برای حل چنین مشکلاتی است:

  1. مسائل بدخیم صورت مسئله مشخصی ندارند: مهمترین معضل در حل مسائل بدخیم نوشتن صورت مسئله است. منظور از «نوشتن صورت مسئله» مشخص کردن سه مورد زیر است:
    • نوشتن ویژگی های حالت ایده آل و حالت فعلی.
    • پیدا کردن علت مشکل. به عبارت دیگر، علت تفاوت بین حالت ایده آل و حالت فعلی چیست؟
    • انتخاب مجموعه ای از اقدامات برای رفع علت مشخص شده.
  2. مسائل بدخیم شرط توقف ندارند: در حل مسائل ریاضی یا موقع بازی شطرنج می دانیم کی مسئله حل شده یا بازی به اتمام رسیده است. اما، مسائل بدخیم شرط توقف ندارند. نمی دانیم مشکل چه موقع حل شده است. در واقع، مجموعه رویدادها و وقایع خاصی وجود ندارند که با رخ دادن آنها متوجه شویم مسئله حل شده است. عموما، کسانی که مسائل بدخیم را حل می کنند به علت اتمام وقت یا بودجه حل مسئله را متوقف می کنند.
  3. راه حل های مسائل بدخیم درست یا غلط نیستند، بلکه خوب یا بد هستند: این ویژگی دخیل بودن عوامل انسانی و قضاوت انسان در بررسی کارایی راه حل مسائل بدخیم را شرح می دهد. در حل مسائل ریاضی، فرد یا افرادی وجود دارند که می توانند با آگاهی از قوانین ریاضیات، راه حل ارائه شده را بررسی کرده و اعلام کنند آیا راه حل ارائه شده درست است یا غلط. اما، در بررسی صحت و کارایی راه حل های مسائل مرتبط با اجتماع سلیقه، بافت جامعه، ساختار اجتماعی و سلسله مراتبی و قضاوت افراد دخیل است. ممکن است راه حل از نظر یک فرد خوب و از نظر شخص دیگری بد باشد.
  4. پیش از پیاده سازی راه حل، تستی برای اینکه مشخص کند آیا راه حلی برای مسئله به دست آمده است وجود ندارد: در مسائل خوش خیم، پیش از پیاده سازی راه حل، می توان تصمیم گرفت راه حل ارائه شده تا چه حد خوب یا بد است. به عبارت دیگر، بررسی و تست راه حل کاملا در کنترل کسانی است که به حل مسئله علاقه مند هستند. در مسائل بدخیم، هر راه حلی، پس از پیاده سازی، موجی از عواقب و نتایج را به همراه خواهد داشت. این موج می تواند به مدت زمان نامتناهی ادامه یابد. به علاوه، ممکن است پس از پیاده سازی راه حل، نتایج به بار آمده آنقدر وخیم باشند که حل کننده گان مسئله به این نتیجه برسند که بهتر بود اصلا راه حلی ارائه نمی شد! نتایج و عواقب راه حل پیاده سازی شده بر زندگی تک تک افراد را نمی توان پیشاپیش و قبل از پیاده سازی راه حل بررسی کرد.
  5. هر راه حلی که برای یک مسئله بدخیم مطرح می شود بسیار حائز اهمیت است و نمی توان با سعی و خطا مسئله را حل کرد: فرض کنید می خواهید مشکلات سیستم آموزشی یک کشور را رفع کنید. نمی توانید این کار را با سعی و خطا انجام دهید. کوچکترین تغییری باعث تحت تاثیر قرار گرفتن زندگی یک یا چند نسل از جامعه می شود.
  6. مسائل بدخیم مجموعه راه حل های قابل شمارشی ندارند. به علاوه، اعمال مشخصی هم وجود ندارد که بتوان از آنها در برنامه ریزی استفاده کرد: راهی وجود ندارد که بتوان بر اساس آن اثبات کرد همه راه حل های یک مسئله بدخیم شناسایی و بررسی شده است. ممکن است به علت تناقض های منطقی که در صورت مسئله وجود دارد اصلا نتوان راه حلی یافت (برای مثال ممکن است در صورت مسئله نیاز به A و نقیض آن ذکر شده باشد). عموما، در زمان تلاش برای حل یک مسئله بدخیم، مجموعه ای از راه حل ها در نظر گرفته می شوند و مجموعه ای دیگر به طور کامل از نظر پنهان می مانند. تلاش برای افزایش اندازه مجموعه راه حل ها و انتخاب یک راه حل خاص تنها به قضاوت وابسته است.
  7. هر مسئله بدخیمی اساسا یکتا است: به ازای هر دو مسئله، می توان حداقل یک وجه تمایز یافت. اما، «اساسا یکتا» یعنی به ازای تعداد بسیار زیادی ویژگی مشابه بین دو مسئله بدخیم، یک ویژگی متمایز کننده وجود دارد که اهمیت بسزایی دارد. در نتیجه نباید برای انتخاب راه حل مسائل بدخیم عجله کرد.
  8. هر مسئله بدخیمی را می توان نشانه ای از یک مسئله بدخیم دیگر (و سطح بالاتر) در نظر گرفت: برای مثال جرم و جنایت را می توان نشانه ای از افول اخلاق در جامعه در نظر گرفت.
  9. توضیحات مختلفی برای وجود تفاوت بین حالت ایده آل و حالت فعلی در صورت مسائل بدخیم قابل ارائه است. اگر توضیح خاصی را به عنوان علت مسئله در نظر بگیرید در واقع راه حل خود را انتخاب کرده اید. برای مثال می توان علت جرم و جنایت در جامعه را افول اخلاق، فقر، تولید فیلم های خشن و غیره دانست. اگر علت خشونت در جامعه را افول اخلاق در نظر بگیرید راه حلتان هم در همین جهت پیش خواهد رفت!
  10. طراح (حل کننده گان مسائل بدخیم) حق اشتباه کردن ندارد: در علم، دانشمندان نظریه های مختلفی برای توضیح یک پدیده بیان می کنند. یک نظریه را می توان با استفاده از شواهد نقض کرد و نظریه جدیدی ارائه داد. هیچ کس، دانشمندان را برای ارائه نظریاتی که نقض می شوند سرزنش نمی کند. اما، در حل مسائل بدخیم، بر خلاف علم، هدف یافتن حقیقت نیست. هدف، بهبود شرایط زندگی مردم است. از این رو طراحان و کسانی که مسائل بدخیم را حل می کنند حق اشتباه کردن ندارند و باید مسئولیت تصمیمات خود را بپذیرند.

هدف فرآیندهای گوناگون تفکر طراحی حل مسائلی است که ویژگی های فوق را دارند. مسائلی که اصطلاحا انسان-محور هستند. این گونه مسائل در بطن جامعه یا سیستمی هایی که عوامل انسانی در آنها نقش دارند (برای مثال سیستم های نرم افزاری) پدید می آیند و برای حل آنها باید نیازهای افراد مختلف در نظر گرفته شود. حال که ویژگی های مسائل بدخیم را برشمردیم می توانید برای مشاهده مراحل گوناگون فرآیند تفکر طراحی (که فرآیندی برای حل این مسائل ارائه می دهد) و انواع مختلف آن به اسلایدها مراجعه کنید. در انتها امیدوارم توضیحات فوق مفید واقع شوند.

برای آگاهی از پست های بعدی می توانید در کانال تلگرام وبلاگ عضو شوید.
برای عضویت در کانال وبلاگ اینجا کلیک کنید

رفتار نرم افزار دربرابر خطا

تصویری که کاربری خیالی را در مواجهه با خطا نشان می دهد

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

در سال ۱۹۸۶ دون نورمن (Don Norman) و کلیتون لوییس (Clayton Lewis) مقاله ای را با عنوان طراحی برای خطا (Designing for error) در کتاب User-Centered System Design چاپ کردند. آنچه در ادامه می خوانید خلاصه این مقاله (با کمی تغییر) است.

اگر با سیستم های کامپیوتری کار کرده باشید حتما با پیغامهای خطا هم مواجه شده اید. برخی از پیغام هایی که ممکن است دیده باشید عبارتند از:

  • فایل یا دایرکتوری مقصد موجود نیست
  • خطا در اتصال به سرویس دهنده
  • خطا در نوشتن فایل در دایرکتوری مقصد

اما آیا استفاده از کلمه خطا (Error) در چنین شرایطی درست است؟ نویسندگان مقاله می گویند خیر! چون خطا کلمه ای است که عموما با شنیدن آن، دنبال مقصر می گردیم. این کلمه بار منفی دارد و کاربر با دیدن آن احساس می کند ناتوانی او باعث خطا شده، در حالیکه نرم افزار نتوانسته به درستی به درخواست یا ورودی کاربر پاسخ دهد. بنابراین نویسندگان مقاله استفاده از هر کلمه دیگری را در این شرایط، بر خطا، مقدم می دانند. به علاوه انسانها همان طور که با دیگر انسانها در تعاملند، با کامپیوترها تعامل (Interact) می کنند. سیستمی که مدعی تعاملی بودن است باید همان طور که دو طرف یک گپ و گفت سعی در رفع اشکالات کلامی و مفهومی هم می کنند (تا حرف هم را بفهمند) سعی کند به کاربر کمک کند و اشکالات او را رفع کند.

اما آیا می توان “خطاهای” کاربر را دسته بندی کرد؟ به طور کلی کاربران هدف یا مقصودی (Intention) برای استفاده از نرم افزار دارند:

  • اگر هدف و مقصود کاربر درست باشد اما عملی که برای دست یافتن به آن انجام می دهد اشتباه باشد او مرتکب لغزش (Slip) شده است
  • اگر هدف و مقصود به کلی اشتباه باشد کاربر مرکتب اشتباه (Mistake) شده است

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

اما رفتار نرم افزارها در برابر خطا به چند دسته تقسیم می شود؟ به طور کلی می توان رفتار نرم افزارها در برابر خطا را به شش دسته زیر تقسیم کرد:

  1. Gag: در این حالت سیستم کار مورد نظر کاربر را انجام نمی دهد. این توقف کاربر را آگاه می کند که خطایی رخ داده، اما کاربر متوجه نمی شود این خطا چیست. برای مثال وقتی سعی می کنید ماشین را روشن کنید اما هیچ اتفاقی نمی افتد. در این حالت متوجه می شوید که مشکلی وجود دارد اما نمی توانید تشخیص دهید این مشکل چیست؟
  2. Do Nothing: در صورت بروز خطا سیستم، هیچ عکس العملی از خود نشان نمی دهد. این روش تنها در شرایطی قابل استفاده است که کاربر متوجه شود در پاسخ به درخواست وی هیچ اتفاقی نیفتاده است، در غیر این صورت ممکن است کاربر به اشتباه فکر کند درخواستش انجام شده است.
  3. Warn: در این حالت در صورت بروز خطا یک اخطار به کاربر نمایش داده می شود اما سیستم به کار خود ادامه می دهد. برای مثال در حین کپی فایل سیستم به کاربر اطلاع می دهد دیسک در حال پر شدن است اما به کپی فایل ادامه می دهد.
  4. Self-Correct: در این روش در صورت خطای کاربر، سیستم سعی می کند به صورت خودکار هدف کاربر را تشخیص و کار مورد نظر او را انجام دهد. این مکانیزم تنها در شرایطی مفید است که بتوان کار انجام شده توسط سیستم را به راحتی لغو کرد. مثالی از این سیستم ها را می توان در برنامه هایی که به صورت خودکار کلمات تایپ شده کاربر را کامل می کنند مشاهده کرد.
  5. Teach Me More: در این حالت اگر نرم افزار نتواند درخواست کاربر را به درستی درک کند از کاربر می خواهد اطلاعات بیشتری در اختیارش قرار دهد. برای مثال دیکشنری هایی که برخی از کلمات را ندارند به کاربر امکان می دهند کلمه ناموجود را اضافه کند.
  6. Let’s Talk About It: این روش که قدمی به سوی تعاملی تر شدن برنامه ها است سعی می کند با برقراری دیالوگ با کاربر مشکل را حل کند. برای مثال با پرسیدن مجموعه ای از سوالات.

توجه داشته باشید رفتار نرم افزار در برابر خطا می تواند ترکیبی از موارد فوق باشد.

آخرین نکته ای که باید در مورد رفتار نرم افزار دربرابر خطا به آن توجه شود پیغام های خطا هستند. پیغام خطا (در صورت نمایش) باید دو نوع اطلاعات مختلف در اختیار کاربر قرار دهد:

  1. اینکه خطایی رخ داده است (Detection of error)
  2. اینکه خطا در چه سطحی از نرم افزار اتفاق افتاده (Identification of error)

عموما پیغام های خطا مورد اول را در اختیار کاربر قرار می دهند اما اطلاعات دقیقی در مورد مکان و علت دقیق رخ دادن خطا به کاربران نمی دهند و این امر می تواند باعث سردرگمی کاربران شود.

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

برای آگاهی از پست های بعدی می توانید در کانال تلگرام وبلاگ عضو شوید.
برای عضویت در کانال وبلاگ اینجا کلیک کنید

هشت اشتباه که باعث از دست دادن کارمندان خوب می شود

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

نگه داشتن کارمندان خوب در شرکت ها کار سختی است (اگر چه نباید چنین باشد). وقتی (به عنوان مدیر یک کمپانی) اشتباهی مرتکب می شوید،  اولین کسانی که از دست می دهید بهترین کارمندانتان هستند، چون بیشترین انتخاب را دارند.
اگر نتوانید بهترین کارمندانتان را دلگرم و درگیر کار نگه دارید، آنها را از دست خواهید داد. اگرچه درک این جمله ساده به نظر می رسد، در واقع چنین نیست! طبق نظرسنجی که CEB انجام داده، یک سوم کارمندان خوب شرکت های مختلف نسبت به کار و کارفرمای خود دلسرد هستند و دنبال یک شغل جدید می گردند.
از دست دادن کارمندان خوب یکباره اتفاق نمی افتد. علاقه به کار در آنها به مرور از دست می رود. مایکل کیبلر که زمان زیادی را صرف مطالعه این پدیده کرده، آن را خاموش شدن می نامد. مثل ستاره های در حال مرگ که به مرور نور خود را از دست می دهند، کارمندان خوب هم عطش و علاقه خود به کار را به مرور از دست می دهند. کیبلر می گوید: “در این حالت به نظر می رسد همه چیز خوب است. کارمندان ساعات زیادی را صرف کار می کنند، در کارهای تیمی مشارکت می کنند و کارهایشان را به خوبی انجام می دهند. اما در واقع دارند در سکوت از پای در می آیند و نتیجه واضح این امر دلسرد شدن است”. برای پیش گیری از خاموش شدن کمپانی ها و مدیران باید بدانند اعمال و تصمیماتشان چگونه بر این امر تاثیر می گذارد. در ادامه برخی از اموری که باعث دلسرد شدن کارمندان خوب می شود و باید از انجام آنها پرهیز کرد را آورده ایم:

  1. آنها قوانین احمقانه زیادی وضع می کنند: همه می دانیم که شرکت ها و کمپانی ها باید قانون مند باشند. اما این قوانین نباید سرسری وضع شوند. حتی وضع تعداد اندکی قانون غیرضروری و اضافه می تواند به شدت باعث ناراحتی افراد شود. وقتی کارمندان خوب احساس کنند همه چیز تحت نظر است و برادر بزرگ همه رفتار و اعمال آنها را مثل یک جاسوس تحت نظر دارد مکان دیگری برای کار پیدا خواهند کرد.
  2. آنها با همه یکسان برخورد می کنند: اگرچه این رفتار با بچه مدرسه ای ها به خوبی جواب می دهد، محیط کار متفاوت است. اگر با همه یکسان برخورد کنید بهترین کارمندانتان فکر می کنند کار کردن اهمیتی ندارد. چون به هر حال چه کار کنند و چه کاری انجام ندهند برخورد شما با آنها یکسان خواهد بود.
  3. کارایی ضعیف برای آنها قابل قبول است:  می گویند در گروه های جاز، گروه به خوبی بدترین نوازنده است. مهم نیست بعضی از اعضا چقدر خوب هستند همه صدای ساز بدترین نوازنده را میشنوند. در شرکت ها هم چنین است. اگر اجازه دهید پیوندهای ضعیف بدون هیچ پیامدی باقی بمانند، همه تیم را باخود پایین می کشند.
  4. آنها به نتایج اهمیت نمی دهند: ممکن است اثر نوازش را دست کم بگیرید، به خصوص در مورد بهترین کارمندانتان که انگیزه ذاتی و غریزی دارند. همه تشویق شدن را دوست دارند، به خصوص کسانی که به سختی کار می کنند و تمام تلاششان را انجام می دهند. پاداش دادن به دست آوردهای افراد نشان می دهد شما به کارهای آنها توجه دارید. مدیران باید با افراد در ارتباط باشند تا بدانند چه چیزهایی آنها را خرسند می کند و برای کارهایی که انجام می دهند به آنها پاداش دهند.
  5. آنها به افراد اهمیت نمی دهند: بیش از نیمی از کسانی که کار خود را رها می کنند، این کار را به خاطر رابطه با مدیرشان انجام می دهند. شرکت های موفق سعی می کنند مدیرانشان را طوری تربیت کنند که بین انسان بودن و حرفه ای بودن متعادل باشند. یعنی مدیرانی که از پیشرفت کارمندانشان خرسند می شوند، در دوران دشواری و سختی با کارمندان همدردی می کنند و آنها را به چالش می کشند. مدیرانی که چنین نیستند نیروهای زیادی را از دست می دهند. هشت ساعت (یا بیشتر) کار در روز با کسی که خود درگیر کار نیست و به چیزی به جز خروجی اهمیت نمی دهد غیر ممکن است!
  6. آنها تصویر بزرگ را به شما نشان نمی دهند: ممکن است فکر کنید تخصیص کارها به کارمندان و پیش روی روشی موثر برای مدیریت است. اما اگر تصویر بزرگ (دید کلی) به کارمندانتان ندهید، به خصوص کارمندان خوب، آنها را از دست خواهید داد. کارمندان خوب فشار کاری بیشتری را تحمل می کنند در نتیجه کارشان باید هدفمند باشد. وقتی هدف آنها مشخص نباشد دلسرد می شوند.
  7. آنها اجازه نمی دهند افراد علایقشان را دنبال کنند: گوگل کارمندانش را مجبور می کند حداقل بیست درصد از زمانشان را صرف کارهایی کنند که “فکر می کنند” در پیشرفت گوگل موثر است. این کارهای داوطلبانه نه تنها تاثیر بسزایی در بسیاری از پروژه های گوگل دارد بلکه موجب دلگرم شدن کارمندان گوگل هم می شود. کارمندان با استعداد به کارشان علاقه مند هستند. فراهم آوردن فرصت هایی که به آنها امکان می دهد علایقشان را دنبال کنند باعث افزایش کارایی و رضایت شغلی آنها می شود.
  8. کارکردن با آنها لذت بخش نیست: اگر مردم از کارشان لذت نبرند، یعنی مدیریت به درستی انجام نمی شود. اگر افراد از کار لذت نبرند تمام توان خود را صرف انجام کار نمی کنند و نسبت به کار دلسرد می شوند. برای مثال گوگل تمام تلاش خود را برای لذت بخش کردن کار انجام می دهد از کلاس های بدنسازی گرفته تا غذای رایگان. ساده است، اگر کار لذت بخش باشد شما ساعات بیشتری در محیط کار صرف می کنید و سالهای بیشتری را به کار می پردازید.

نتیجه گیری

به یاد داشته باشید مردم کارشان را رها نمی کنند بلکه مدیرشان را رها می کنند! می خواهید محیط کار بهتری را فراهم کنید؟ سعی کنید درباره EQ بیشتر بیاموزید.

 

برای آگاهی از پست های بعدی می توانید در کانال تلگرام وبلاگ عضو شوید.
برای عضویت در کانال وبلاگ اینجا کلیک کنید

 

تاریخچه سیستم های کنترل نسخه

طبق آنچه در ویکیشنری آمده کلمه Version، که در فارسی به نسخه ترجمه شده، از قرن شانزدهم در زبان انگلیسی به کار می رفته است. این کلمه یعنی: “فرم (صورت) دیگری از چیزی”. می توان در مهندسی نرم افزار کلمه “چیزی” را همان نسخه صفر کد (Initial commit) در نظر گرفت. در این حالت “فرم های دیگر” تغییراتی هستند که به مرور روی نسخه صفر کد انجام می شود تا نرم افزار نهایی به دست آید.

اما در اصطلاح “کنترل نسخه”، که معادل فارسی Version Control است به جز Version کلمه دیگری هم وجود دارد (کلمه Control). می توان گفت کنترل در اینجا به معنای مدیریت است.

تا اینجا اجزای اصطلاح کنترل نسخه را یک به یک بررسی کردیم! حال، نوبت به تعریف این اصطلاح در مهندسی نرم افزار است. در ادامه این تعریف را از منظر دو منبع بررسی می کنیم:

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

در واقع سیستم کنترل نسخه به شما و تیمتان امکان می دهد تغییرات اعمال شده در طول مدت پروژه را  دنبال کنید و مثل Microsoft Word امکان Undo و Redo برایتان فراهم می آورد. در واقع می توان گفت سیستم های کنترل نسخه دو ویژگی اصلی در اختیارتان قرار می دهند:

  • با ذخیره سازی مجموعه تغییرات اعمال شده به کد به شما امکان بازگشت به نسخه های قبلی کد پیش از تغییرات را می دهند
  • با استفاده از آنها در یک تیم می توانید ببینید کدام اعضای تیم چه تغییراتی را ایجاد کرده اند و این تغییرات چه اثری در محصول نهایی داشته اند

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

در حال حاضر سیستم های کنترل نسخه بسیاری وجود دارند. سیستم هایی مثل Subversion، Git، Mercurial و غیره. ممکن است از خود بپرسید تفاوت این سیستم ها در چیست و کدام یک برای کار شما مناسب تر است؟ در واقع بر اساس مدل کارکرد می توان سیستم های کنترل نسخه را به سه دسته مختلف تقسیم کرد:

  • سیستم های کنترل نسخه محلی: این سیستم ها برای یک کاربر طراحی شده اند و فایل ها را روی هارددیسک کاربر نگه داری می کنند و امکان استفاده تحت شبکه ندارند مثل RCS یا SCCS. به علاوه در این سیستم ها چند کاربر نمی توانند به صورت همزمان فایلی را تغییر دهند
  • سیستم های کنترل نسخه متمرکز: در این سیستم ها یک سرویس دهنده وجود دارد که فایل های مورد نظر روی آن قرار دارند. کاربران باید ابتدا آخرین نسخه پروژه را دریافت کنند. تغییرات مورد نظر را انجام دهند و در نهایت کدهای تغییر یافته را به سرویس دهنده ارسال کنند. اگر موقع ارسال مشخص شود کاربر دیگری قبلا همین فایل ها را تغییر داده پیش از ارسال باید تغییرات اعمال شود. برخی از سیستم های این گروه عبارتند از Subversion، CVS و غیره.
  • سیستم های کنترل نسخه توزیع شده: در سیستم های توزیع شده یک نسخه مرکزی از فایل ها وجود ندارد و هر کاربری تمامی تاریخچه پروژه ( بر خلاف سیستم های متمرکز که کاربران فقط نسخه آخر را در اختیار دارند) را در اختیار دارد. هر کاربر تغییرات مورد نظر خود را اعمال کرده و در نسخه محلی خود ذخیره می کند. در این حالت کاربران می توانند پس از اتمام تغییرات نسخه محلی خود را با یک نسخه راه دور همگام سازی کنند. سیستم هایی مثل Git و Mercurial از این مدل استفاده می کنند.

اما کدام مدل برای شما مناسب تر است؟ در حال حاضر پر کاربرد ترین سیستم موجود Git است اما ممکن است بسته به نیازی که دارید یک سیستم متمرکز پاسخ گوی تمامی نیازهایتان باشد. اگر تیم نرم افزاریتان در نواحی مختلف جغرافیایی هستند محتملا یک سیستم توزیع شده برای شما مناسب تر است اما اگر همه اعضای تیمتان در یک مکان متمرکز هستند می توانید از سیستم های متمرکز هم استفاده کنید. اگر فقط به مدیریت نسخه فایلهای شخصی تان نیاز دارید یک سیستم محلی هم پاسخ گوی نیازتان هست!

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

برای آگاهی از پست های بعدی می توانید در کانال تلگرام وبلاگ عضو شوید.
برای عضویت در کانال وبلاگ اینجا کلیک کنید

 

دروغ های فنی در پروژه های نرم افزاری

دروغ گویی در پروژه های نرم افزاری بسیار رایج است!  اصولا دروغ گو ها در پروژه های نرم افزاری خوب پیشرفت می کنند. به نظرم یکی از دلایل این پیشرفت، ماهیت غیر قابل لمس نرم افزار است. اگر در پروژه های نرم افزاری کار کرده باشید احتمالا با این پدیده مواجه شده اید. در این باره مقالات متعددی وجود دارد. در یکی از این مقالات که رابرت گلس و سایرین با عنوان “Lying on software projects” به چاپ رسانیده اند اطلاعات جالبی در این باره وجود دارد. که در این پست باهم به بررسی آن می پردازیم.

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

  • افزایش میزان فروش نرم افزار
  • دروغ گویی در مقایسه با گفتن حقیقت مزایای بیشتری دارد
  • خوب جلوه کردن در نظر مدیران یا مشتریان
  • اعتماد به نفس کاذب
  • پنهان کردن اشتباهات
  • تلاش برای کاهش بار کاری

طبق مشاهدات من بیشتر دروغ ها به علت خوب جلوه کردن در نظر مدیران (یعنی حقوق و مزایای بهتر)، پنهان کردن اشتباهات (بازهم حقوق و مزایای بهتر) و اعتماد به نفس کاذب (خود نابغه پنداری) بسیاری از نیروهای مدیریتی و اجرایی است که در حیطه نرم افزار کار می کنند.

متاسفانه در بسیاری از پروژه های نرم افزاری دروغ گویان نتایج بهتری از نظر مبلغ دریافتی و رتبه کاری کسب می کنند. علت این امر بی تجربگی بسیاری از مدیران و ناتوانی فنی آنها برای یافتن حقیقت یا دروغ گو بودن خود مدیران است!  این در حالی است که این نتایج در قبال کاری که انجام می شود نیست بلکه تنها حاصل مجموعه ای از دروغ ها است!

این دروغ گوهای خوش خط و خال به راحتی با مجموعه ای دروغ که اثبات خلاف بودن آنها به راحتی ممکن نیست و تنها با گذشت زمان و به بار آوردن خسارات برای مدیران مشخص می شود اعتماد مدیران را جلب کرده و به سادگی یک شبه ره صد ساله می روند. البته به نظر من اگر مدیر خود دروغ گو نباشد اما به راحتی فریب این دروغ گویان را بخورد یعنی مدیر خوبی نیست! مدیریت صحیح نیازمند سنجه (Metric) است تا بتوان با سنجه ها تصمیم گیری کرد. ویژگی که اکثر مدیران ما از آن بی بهره اند.

البته ماه هیچ گاه پشت ابر نمی ماند…

برای آگاهی از پست های بعدی می توانید در کانال تلگرام وبلاگ عضو شوید.
برای عضویت در کانال وبلاگ اینجا کلیک کنید

نرم افزارهایی برای مراقبت از چشم

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

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

اما Iris تنها راه حل موجود نیست. نرم افزارهای بسیار دیگری هم وجود دارند. در این میان از نظر بنده Eye care plus هم نرم افزار بسیار خوبی است. این برنامه قابلیت نصب روی گوشی اندروید شما را داشته و روزی سه بار (صبح، ظهر و شب) مجموعه تمرینات بسیار خوبی به شما پیشنهاد می دهد. اگر تا به حال به اپتومتریست مراجعه کرده باشید ممکن است با برخی از این تمرینات آشنا باشید. این نرم افزار طراحی و رابط کاربری بسیار مناسبی دارد و پیشنهاد می کنم حتما آن را امتحان کنید. می توانید این نرم افزار را از اینجا دانلود و نصب کنید

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

برای آگاهی از پست های بعدی می توانید در کانال تلگرام وبلاگ عضو شوید.
برای عضویت در کانال وبلاگ اینجا کلیک کنید

درس افزار دانشگاه صنعتی شریف

درس افزار، سیستمی است که محتوای کلاس های درسی دانشگاه با استفاده از آن در اختیار عموم قرار می گیرد. این محتوا شامل فیلم، تمرین ها و … می شود. اولین درس افزار ها طبق اطلاعات موجود در صفحه درس افزار ویکی پدیا در اواخر دهه نود در اروپا و امریکا عرضه شدند و امروز پس از گذشت حدودا هجده سال از تولد چنین سیستم هایی و مشخص شدن همه جزئیات اکوسیستم آنها دانشگاه شریف اقدام به راه اندازی این سیستم کرده است. هرچند این سیستم تا بلوغ کامل راه زیادی در پیش دارد اما تاسیس آن اقدام بسیار مثبتی از سوی دانشگاه صنعتی شریف است. می توانید با مراجعه به وبسایت http://ocw.sharif.edu از مطالب آن استفاده کنید.

برای آگاهی از پست های بعدی می توانید در کانال تلگرام وبلاگ عضو شوید.
برای عضویت در کانال وبلاگ اینجا کلیک کنید

اثر راشومون و روش های مدیریت چابک (اجایل)

rashomon-effect

دیروز به درخواست “مدیران” ارائه ای بسیار مقدماتی در مورد روش های چابک در مدیریت نرم افزار به تیم توسعه نرم افزار داشتم! در زمان ارائه به نظر می رسید نظر حضار مختلف در مورد روش های چابک نوعی اثر راشومون است- اثر راشومون حالتی را توصیف می کند که در آن برداشت افراد از، مشاهده ای یکسان، متفاوت است- و هر کسی با شنیده های جسته و گریخته نظری در مورد این روش ها دارد. در واقع بیشتر حضار تعریف و آگاهی درستی از این امر نداشتند. این آگاهی نصفه و نیمه بسیار مشکل ساز است و می تواند باعث ضایع شدن حق کارکنان شود. اما چطور؟
برای مثال یکی از ارزش های اصلی روش های چابک کاهش نقش مدیر به عنوان قدرت مرکزی (دیکتاتور) و توزیع آن بین اعضای تیم و تاکید بر نقش مدیر به عنوان رهبر تیم (نقش واقعی مدیریت) است نه تعیین کننده سرنوشت اعضا. متاسفانه بسیاری و شاید حتی خود من اگر سرنوشت گروهی را به دست بگیریم فکر می کنیم بهترین تصمیم گیرنده ایم و هیچ گاه سعی در یادگیری نداریم چون بهترین تصمیم گیرنده و دانای کل نیاز به یادگیری ندارد. حال اگر افراد از اصول سازمانی روش های چابک اطلاعی نداشته باشند و فقط روی روش های تکنیکی تمرکز کنند ممکن است قربانی سوء استفاده شوند. اما اگر دیدگاهشان را به هم نزدیک کنند و هم صدا و هم کلام شوند می توانند بر مشکلات این چنینی پیروز شوند.
در این ۱۰ سالی که در صنعت آی تی ایران مشغول به کار هستم مشاهدات گاها عجیب و تلخی داشتم و در سازمان های مختلف با افراد گوناگونی مواجه شدم. مشاهداتی که برای بنده مشاهده کننده گاها ناخوشایند، عجیب و غیرقابل باور بوده.از کارکنان و شرکت های خوب این صنعت گرفته تا شرکت هایی با سیاست های شبیه به زندان و شارلاتان هایی که برای مقام یا دریافتی بیشتر دست به هر کاری می زنند(واقعا هر کاری!!!). از تیم های کوچک اما موفق تا تیم های بزرگ اما ناموفق. جا دارد از مصاحبه های عجیب و غریب برخی شرکت ها هم یاد کنم. مصاحبه هایی توسط افرادی بیسواد و بدون آگاهی برای بزرگ جلوه دادن کارهای شرکتی پوشالی که وقتی وارد آن می شوید میبینید کار خاصی در آنها انجام نمی شود.
متاسفانه بسیاری از مشکلات تیم های نرم افزاری و شاید هر تیم تولیدی دیگری از کارکنان فنی نیست بلکه به دلیل مدیریت اشتباه و ناآگاهی های مدیران ماست. این امر زمانی بروز می کند که بسیاری از تیم های نرم افزاری ما اصول تکنیکی روش های چابک را رعایت می کنند اما خبری از رعایت صحیح اصول سازمانی نیست! هر چند اصول روش های چابک وحی منزل نیستند و نیازمندی بر رعایت تمامی آنها نیست اما در بسیاری از مشاهدات من اصول سازمانی به درستی رعایت نمی شوند و حق افراد زیر پا گذاشته می شود.