Teach Yourself Microsoft Dynamics CRM 4 in 24 Hours

در رابطه با کاری که درگیر آن بوده و هستم(راه اندازی و توسعه Microsoft CRM)، با کتابی در این زمینه آشنا شدم که در پیشرفت کار بی تأثیر نبود و باعث شد درک خوبی از این سیستم پیدا کنم.

این کتاب ۴۸۰ صفحه ای برای تمامی کاربران و توسعه دهندگان Microsoft CRM مفید است و دید نسبتاً جامعی از این سیستم در زمان کوتاهی بدست داده، با انتقال مناسب مفاهیم، کمک زیادی به استفاده صحیح و توسعه مناسب این سیستم می کند.

Sams Teach Yourself Microsoft Dynamics CRM 4 in 24 Hours

تولد

امروز تولدم بود. فکر کنم ۲۷ ساله شدم!

Categories: عمومی Tags:

خونه

چند روزی هست که دنبال خونه ام.

و همچنان خونه دلخواهمان را پیدا نکرده ام.

Categories: عمومی Tags:

قصه ی لاک پشت ها!

۲۸ فروردین ۱۳۸۹ علیرضا اسماعیلی ۲ دیدگاه

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

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

لاک پشت کوچولو ناله کرد، جیغ کشید و توی لاکش کلی بالا و پایین پرید، گر چه او سریعترین لاک پشت بین لاک پشت های کند بود!

او قبول کرد که به یک شرط بره؛ اینکه هیچ کس تا وقتی اون برنگشته چیزی نخوره.
خانواده قبول کردن و لاک پشت کوچولو به راه افتاد.

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

در این هنگام لاک پشت کوچولو ناگهان فریاد کنان از پشت یک درخت بیرون پرید،« دیدید می دونستم که منتظر نمی مونید. منم حالا نمی رم نمک بیارم»!

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

منبع: نامه ای از دوست عزیزم آقای جاودانی

Categories: عمومی Tags:

طراحی خوب – قسمت دوم

در مطلب قبلی معیارهای یک طراحی خوب را از زبان آقای Meyers، بیان کردیم.

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

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

  • طراحی معماری
  • طراحی کلاس ها
  • طراحی واسط کاربری
  • طراحی بانک اطلاعاتی
  • طراحی الگوریتم
  • طراحی پروتکل

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

در زیر به برخی از این اهداف اشاره می کنیم:

  • افزایش سود خالص با کاهش هزینه های تولید و افزایش درآمد که برای بیشتر سازمانها این مهمترین هدف است.
  • حصول اطمینان از پوشش دادن نیازمندی های مشتری و حل مسائل وی
  • شتاب دادن به توسعه. که این هدف باعث کوتاه مدت شدن هزینه ها می شود و اطمینان می دهد که نرم افزار برای یک رقابت موثر و به موقع(در زمان تعیین شده توسط مشتری) به بازار ارائه می گردد.
  • افزایش شاخص های کیفیت مانند usability، efficiency، reliability، maintainability و reusability که خود به نحوی باعث پایین آمدن هزینه ها و افزایش درآمد می شود.

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

James Shore در مقاله خود(Quality With a Name) اینطور می گوید:

A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance.

در این مقاله کیفیت طراحی اینگونه تعریف می شود:

Design quality = change / developer time

 

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

برای کامل تر شدن بحث از مقاله آقای Fowler کمک می گیریم. در این نمودار محور cumulative functionality همان قابلیت تجمعی(نه قابلیت مقطعی) است.

 

این نمودار نشان می دهد که نداشتن طراحی(عدم تلاش برای یک طراحی خوب) باعث پیشرفت سریع پروژه در ابتدای مسیر می شود اما به مرور زمان Productivity و کیفیت نرم افزار رو به افول می گذارد. نداشتن طراحی خوب باعث می شود تا به مرور زمان اعمال تغییرات در نرم افزار با سختی بیشتری انجام شود. در صورتی که با داشتن طراحی خوب، Productivity پایدارتر خواهد بود. نکته اینکه این دوخط(good design و no design) در نقطه ای از زمان یکدیگر را قطع می کنند. خط فرضی که از این تقاطع عبور می کند(design payoff line)، نقطه تصمیم گیری است. یعنی اگر میزان قابلیت های تجمعی نرم افزار شما در طول زمان زیر این خط فرضی باشد، عدم تلاش برای یک طراحی خوب تصمیم بهتری است و بالعکس٫ در واقع تصمیم گیری بر اساس این انجام می شود که قابلیت های این نرم افزار در آینده قرار است تا چه اندازه توسعه داده شود.

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

از نظرات دوستان در تکمیل این مطلب استقبال می کنم.

Categories: طراحی Tags: ,

سال نو مبارک

۸ فروردین ۱۳۸۹ علیرضا اسماعیلی ۲ دیدگاه

نرم نرمک می رسد اینک بهار،

خوش به حال روزگار!

ای دریغ از تو اگر چون گل نرقصی با نسیم،

ای دریغ از من اگر مستم نسازد آفتاب!

ای دریغ از ما اگر کامی نگیریم از بهار.

norouz

بهاران خجسته باد!

Categories: عمومی Tags: ,

معیارهای تشخیص یک طراحی خوب – قسمت اول

اولین تمرین جلسه Design Pattern مهندس مهرداد، معیارهای تشخیص یک طراحی خوب بود. به نظر من مقاله آقای Meyers (در وب سایت آقای Fowler) پاسخ مناسبی برای این پرسش است. در این مقاله طراحی از جنبه Interface Specification و با ذکر مثال مورد بررسی قرار گرفته است. خواندن این مقاله را به دوستان توصیه می کنم. Meyers مهمترین رهنمون برای طراحی یک Interface ی خوب را اینگونه بیان می کند:

Make interfaces easy to use correctly and hard to use incorrectly.

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

Meyers می گوید:

responsibility for interface usage errors belongs to the interface designer, not the interface user.


 بروزرسانی(۲ فروردین ۱۳۸۹)

دوست عزیزی(آقای صفری) در بخش نظرات نوشته بودند:

به قول Steve Jobs طراحی باید به گونه ای باشد که محصول ما انگار روح دارد . ایشون طراحی را یک لایه برروی هسته نمی داند همانطور که خودش اذعان دارد iPod روح دارد یعنی این روح با کاربر ارتباط برقرار می کند .

الحق به خاطر همین روحیه است که Apple اینقدر موفق است .

مقاله ایشان در باب طراحی قابل توجه است.

بازگشت

متاسفانه بنا به دلایلی نوشته های اخیر فردامدیا رفت روی هوا(!) و مجبور شدم دوباره شروع کنیم.

انگیزه اصلی نوشتنم شروع کلاس پربار Design Pattern توسط استاد عزیزم مهندس مهرداد در موسسه فراتر از دانش و پیگیری ایشان بود.

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