نحوه نصب ویندوز سرویس سفارشی

{ ارسال شده در ۲۱ تیر ۱۳۹۲ توسط حمیدرضا }
برچسب ها : ,
مربوط به : توسعه وب

گاهی اوقات لازم میشه که روی یک سرور اختصاصی بخواین ویندوز سرویس سفارشی راه اندازی کنید و بعد از توسعه یک پروژه Windows Service در VS و تهیه فایل exe، هنگام نصب روی سرور با پیغام خطا مواجه بشین! نکته اینجاست که برای نصب و راه اندازی یک پروژه ویندوز سرویس از ابزاری به نام Installutil.exe باید استفاده کنید. این فایل در مسیر Windows\Microsoft.NET\Framework64 قرار داره که بر حسب ورژن دات نت فریم ورک در پوشه مربوطه قرار گرفته( طبیعتاً اگر ویندوز سرور شما ۳۲ بیت است در پوشه Framework باید به دنبالش باشید). عملیات نصب هم به این صورت است که این فایل رو در cmd به همراه مسیر فایل exe پروژه وارد و Enter کنید سرویس به راحتی به Services ویندوز اضافه میشه که اگر Autorun نیست باید به Services مراجعه و Startش کنید. + +

موفق باشید.

۲۴ تله ی رایج در اسکرام (بخش اول)

{ ارسال شده در ۰۴ اردیبهشت ۱۳۹۲ توسط حمیدرضا }

همونطور که می دونید اسکرام محبوب ترین متد Agile است اما انجام صحیح اسکرام کار ساده ای نیست! برای این که شما هم بتونید اسکرام را درست پیش ببرید مواظب باشید در این تله ها گرفتار نشین.scrum_01

۱ افراط در مقدمه­ سازی و برنامه ریزی. قبل از شروع هر اسپرینت در اسکرام نیازی نیست مته به خشخاش بذارید و بخواین در ابتدا مقدمات برگزاری اسپرینت آماده بشه و بعد اون رو برگزار کنید. این اتفاق مخصوصاً در اسپرینت اول خیلی اتفاق میفته. کار رو شروع کنید و در Sprint Review آنچه که اتفاق افتاده رو بررسی کنید. حتی اگر Product Backlog هم برای اسپرینت اول آماده نیست باز مشکلی وجود نداره و می تونید این اسپرینت رو برگزار کنید.

۲ تمرکز بیش از حد  بر روی ابزار. خیلی از افراد یا شرکت ها مرتب دنبال این هستن که ببینن چه ابزار جدیدی اومده که میتونه در جهت پیشبرد اسکرام بهشون کمک کنه حتی اگر ندونن اصلاً اسکرام چی هست. اولین چیزی هم که در مباحثه ها به شما میگن اینه که ما از فلان ابزار استفاده می کنیم شما از چی استفاده می کنین؟! انگار اسکرام کِرِم دور چشم شده که مارکش مهم باشه! واقعاً شما اسکرام رو با همون حداقل ابزارهای خودش میتونین پیش ببرید. نهایت امر یه Excel نیاز خواهید داشت و لا غیر. وقتی رو هم که صرف جستجو، یادگیری و آزمون و خطای این می کنید که کدوم ابزار به کار شما میاد رو صرف افزایش دانشتون در خود اسکرام کنید.
۳ حل مشکلات در جلسه Stand-up. این جلسه، از جلسه های کوتاه بسیار مفید در اسکرام است و قرار نیست به طول بیانجامد. هرگز وقت این جلسه رو صرف بررسی چراها، علت ها، تعیین مقصرین، نق زدن ها، داستان گفتن ها و … نکنید. همون سه سوال اصلی رو کوتاه و مختصر پاسخ بدید. اسکرام مستر در این جلسه نقش کلیدی ای رو بازی میکنه.
۴ تعیین وظیفه برای اعضای تیم. اساس تیم در اسکرام بر اساس self-organized بودن اون است و چیزی به نام Task-Assign توسط هر عضوی از تیم یا سازمان کارفرما یا سازمان مجری در اسکرام وجود نداره. واقعاً اگه روحیه و فرهنگ این کار رو ندارید اسکرام رو انتخاب نکنید! کاری که میتونه انجام بشه ایجاد اشتیاق در اعضای تیم برای انتخاب یک Task است.
۵ تاخیر در شروع مجدد یک Sprint. اگرچه کنسل شدن یک اسپرینت خیلی نادر است اما این میتونه خیلی وسوسه انگیز باشه که اول صبر کنیم تا همه چی آماده و اوکی بشه بعد اسپرینت رو مجددا شروع  کنیم. بعد از اینکه اسپرینت به هر دلیلی کنسل شد تیم می بایست به سرعت اسپرینت رو مجدد شروع کنه بدون هیچ تاخیری.
۶ Scrum Master در نقش مشارکت کننده در انجام Taskها. اسکرام مستر مثل آتش نشان میمونه. بیکار بودنش اشکالی نداره، میتونه فعالیت تیم رو نظاره کنه و منتظر باشه تا مانعی اتفاق بیفته تا وارد شه. اما اگر بخواد چون وقتش خالی است پس در انجام Taskای مشارکت جدی کنه و یا مسئولیتی از اعضای تیم توسعه رو بعهده بگیره این باعث میشه از وظیفه اصلیش که بر طرف کردن موانعی است که بر سر راه تیم ممکنه پیش بیاد و یا هر آنچه که در فعالیت تیم وقفه ایجاد میکنه دور بمونه.
۷ غیبت Product Owner. مالک محصول یک عضو تمام وقت تیم اسکرام است و باید در جلسات اسکرام مانند Planning، Review و یا Daily حضور داشته باشه.  کلاً باید در طول تایم کاری فعال و در دسترس تیم باشه. نبود اون تیم رو دچار مشکل خواهد کرد.
۸ افراط در هدف گذاری یک اسپرینت. تیم تصمیم میگیره که در طول یک اسپرینت چه کارهایی رو میتونه انجام بده و در واقع توانش چقدر است. هیچ کس نمیتونه به تیم فشار بیاره تا حجم کار بیشتری رو انجام بده. در صورت این اتفاق اعضای تیم آزرده خاطر خواهند شد و مطمئناً کیفیت کار پایین میاد.
۹ قهرمان سازی های فردگرایانه. اسکرام به ما کمک می کنه تا از افراد تیم های خوبی بسازیم نه تیم هایی از افراد خوب بسازیم(Barry Turner)! شخص واحد در اسکرام جایگاهی نداره. اگر محصول با ارزش و موفق است کل تیم نقش داره و اگر شکست خورده باز کل تیم مقصر است. ممکن است یکی از اعضای تیم رو قهرمان موفقیت ها بدونن که این اشتباه است و انگیزه رو از سایرین خواهد گرفت.

۱۰ تیم به تنهایی پروداکت  بک لاگ رو سازماندهی میکنه. تیم ِتوسعه اطلاعی از نیازهای مشتری و اولویت بندی اونها بر اساس ROI نداره در نتیجه نمیتونه آیتم های پروداکت بک لاگ رو اولویت دهی و سازماندهی کنه. این وظیفه مالک محصول است که این کار رو انجام بده. تنها کاری که تیم میتونه در این قسمت انجام بده مشارکت با PO در اولویت بندی هایی است که از لحاظ تکنیکالی باید جابجا بشن و امکان انجامش از لحاظ فنی نیست.

۱۱ تعیین راه حل توسط Product Owner. مالک محصول می بایست از تمامی اعضای تیم در مورد تعیین راه حل برای مشکلاتی که ممکن است در پروداکت بک لاگ پیش بیاد مشورت بگیره و خودش نباید مستقیماً تصمیم بگیره و به نظر تیم احترام نذاره.

۱۲ وقفه های اورژانسی: این وقفه ها نباید در طول یک اسپرینت اتفاق بیفتن و باعث طولانی شدن اسپرینت بشن. در عوض اگر تا حد زیادی ضروری است می بایست اسپرینت توسط تیم کنسل بشه. بعبارت دیگه عامل وقفه باید در پروداکت بک لاگ قرار بگیره و تا در اسپرینت جدید بهش رسیدگی بشه.

یوزر اینترفیس به سبک اجایل #۳

{ ارسال شده در ۳۰ آبان ۱۳۹۱ توسط حمیدرضا }
برچسب ها : , , , ,
مربوط به : توسعه وب

و اما قسمت آخر؛ در دو پست قبلی کلیاتی درباره UI Development مطرح شد. در این قسمت بصورت کاربردی تر به این موضوع خواهم پرداخت.  همونطور که می دونید Iterative(تکرارشونده) و Incremental(تدریجی)  بودن توسعه، دو اصل حیاتی در بطن Agile هستن. بعضی ها فکر می کنن که این دو مورد فقط باید در توسعه Back-End محصول دیده بشه! بر خلاف این نظر در توسعه Front-End هم رعایت این دو اصل الزامی است.  دقت کنید جداسازی Front-End و Back-End از لحاظ تکنیک های پیاده سازی است و در خروجی یک چیز بیشتر نیست و اون کل محصوله که یک ماهیت بیشتر نداره. نکته ای که مهم است اینه که به Front-End نگاه Design و Development رو تواماً داشته باشید.images

خوب حالا فرض کنید محصولی رو با استفاده از اسکرام قرار است تولید کنید. سوال اینه که یوزر اینترفیس رو از کجای چرخه توسعه نرم افزار باید شروع کنیم و دو اصل کلیدی فوق رو به چه صورت پیاده کنیم؟ عموماً در اکثر تیم های اسکرام، اسپرینت صفر (۰) وجود داره. بهترین زمان برای ترسیم یک شِمای کلی از اینترفیس در همین اسپرینت صفر است که می تونید در قالب پروتوتایپ های کاغذی آماده بشه و به پروداکت اونر ارائه شه. استفاده از پروتوتایپ های کاغذی مطابق با دو اصل کلیدی است. آهسته و پیوسته حرکت می کنیم و No More, No Less رو از همون ابتدای کار بهش توجه می کنیم. پروتوتایپ های کاغذی رو حتماً جدی بگیرید. به نظر من بعنوان یک عادت خوب قبل از شروع کدنویسیِ یک Task مرتبط با UI حتماً قبلش پروتوتایپ کاغذی ش رو داشته باشید. مزیت این کار این هست که آمادگیتون برای تغییر روی کاغذ خیلی بیشتر از حالتی است که کد نوشته شده. شما براحتی می تونید در حین صحبت با پروداکت اونر تغییرات لازم رو روی پروتوتایپ کاغذی بدید. قرار هم نیست در اسپرینت های ابتدایی کل UI بسته شه. در واقع روند تکامل تدریجی و تکرارشونده در کل اسپرینت ها وجود داره. مسلماً تا آیتم های بگ لاگ به یه حدی نرسه شروع طراحی پروتوتایپ های کاغذی معنایی نداره. شما در این زمان میتونید Mock-up های آماده برای فرم هایی مثل Login، ثبت نام یا گریدها داشته باشید. طبیعتاً این کار در ادامه باعث صرفه جویی در زمان میشه که شما میتونید از این زمان بدست اومده در جهت بالابردن کارایی UI و بهترکردن UX استفاده کنید. در جلسه Sprint Planning سعی کنید DoD رو برای UI خیلی کامل در نظر نگیرید البته نظر PO در این قسمت مهم تر است ولی بطور کلی سعی کنید اسپرینت به اسپرینت UI یک Task خاص رو تکمیل کنید در همون حدی که مورد انتظار PO است نه بیشتر و نه کمتر. توسعه Front-End چیزی است که شاید در طول اسپرینت های اولیه خیلی دستخوش تغییر بشه تا stable بشه. تا اون زمان سعی کنید از دوباره کاری ها جلوگیری کنید. معیار Just Enough  بر می گرده به DoD ای که برای هر Task در نظر گرفته شده. پس با کمک تیم و PO و با کمک پروتوتایپ های کاغذی که قبلاً رسم کردید حتماً DoD رو در Sprint Planning مشخص کنید تا دوباره کاری صورت نگیره.

سعی کنید CSS Library آماده ای داشته باشید. بسته به نوع تمپلیت منوهای آماده، کنترل های تست شده و Design Pattern های مختلف در جعبه ابزار تیم داشته باشید تا بتونید وقت خودتون صرف آیتم های با اولویت تر کنید تا اینکه تیم یک هفته برای یک منوی Cross-Browser وقت بگذاره. دو اصل کلیدی بیان شده باعث میشه شما همیشه آمادگی لازم برای تغییرات رو داشته باشید. پاسخگویی مناسب به تغییرات درخواست شده از جانب مشتری از ارزش های مهم در Agile است. اگر تیم از تغییرات UI استقبال نمیکنه و دائم غر غر می کنه مطمئن باشید بعضی از مواردی که در بالا بیان شد رعایت نشده. ارتباطات در تیم اسکرام خیلی مهم است سعی کنید بین اعضای تیم، اسکرام مستر و پروداکت اونر ارتباطات رو به بهترین شکل مدیریت کنید.

علاوه بر تکمیل UI مربوط به یوزر استوری های هر اسپرینت که همون اسپرینت بگ لاگ میشه یک برنامه ریزی کلی متناسب با رلیز پلن برای UI داشته باشید. در مورد UX حتماً با سایر ذینفعان محصول صحبت کنید و به PO اکتفاء نکنید. مواردی که مد نظرشون رو هست رو حتماً لحاظ کنید. طبیعی است که صحبت با ذینفعان بصورت پیوسته از ابتدای کار تا انتهای کار باید مستمر باشه. مثلاً در جلسات مختلفی که ذینفعان هستن میتونید فیدبک ها رو یادداشت کنید. یا اگر محصول رلیز به رلیز در محیط مشتری مستقر میشه به اونجا برید و فیدبک ها را جمع آوری کنید. همیشه سعی کنید شما دنبال فیدبک باشید نه اینکه منتظر باشید فیدبک خودش بیاد.

نکته آخر این که Cross-Functional بودن تیم اسکرام نقطه مثبتی است در بهتر شدن فرآیند طراحی UI. چراکه افراد مستقیماً با یوزر استوری ها و حتی مواردی که مربوط به تحلیل و جمع آوری نیازمندی ها است در ارتباط هستن، در جلسات مختلفی مثل Sprint Review و Retrospective از نزدیک درگیر پروژه هستن که این موضوع دید کلی اونها رو نسبت به محصول تقویت میکنه و در ادامه کار از کوچکترین مساله ای که در بک لاگ اتفاق میفته مطلع میشن و این انسجام کاری باعث بهتر شدن فرآیند تولید محصول میشه.

امیدوارم این ۳ پست تونسته باشه به شما در طراحی UI به سبک اجایل کمک کنه.

موفق باشید.

Windows Phone SDK 8.0 Released

{ ارسال شده در ۱۰ آبان ۱۳۹۱ توسط حمیدرضا }

کیت توسعه نرم افزار ویندوز فون ۸ منتشر شد. +

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

{ ارسال شده در ۲۷ مهر ۱۳۹۱ توسط حمیدرضا }

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

نکته ای که در این سوال وجود داره اینه که افراد مختلف با در نظر گرفتن تجربه و تخصص خودشون به این سوال جواب های متفاوتی میدن مثلاً جواب یک برنامه نویس با دو سال سابقه کاری با یک تحلیلگر با ۵ سال سابقه کاری متفاوت هست. دقت کنید کلیات تئوری جواب ها تا حدودی به هم شبیه هست ولی منظر اجرایی اون ها با هم متفاوت هست. مخصوصاً در Scale های مختلف پروژه. اما هدف از این سوال چی هست؟ شما در هر شرکت نرم افزاری دلایل شکست و موفقیت پروژه های نرم افزاری رو جویا بشی می بینی که یک لیست خیلی خوب رو می نویسن. همه به این دلایل واقف هستن اما چی میشه که باز پروژه موفق نمیشه؟ فاکتورهای زیادی میتونه در این مساله نقش داشته باشه ولی یکی از مهمترین اون ها نقشه مسیر انجام هر پروژه هست که در واقع همون سوالی هست که در ابتدا پرسیدم. دقت کنید خود تهیه نقشه مسیر یه بحثه و طبق اون نقشه پیش رفتن هم یه بحثه دیگه هست که هر دو مهم هستن. هر پروژه هم برای خودش نقشه جداگانه ای داره و هر فردی با توجه به تخصص و تجربه اش میتونه نقشه متفاوتی برای هر پروژه ترسیم کنه. اما هدف من صرفاً شیوه رسم نقشه نیست. اون چیزی که مهمه اینه که آیا میشه با وجود اینکه هنوز نقشه کامل نشده حرکت رو شروع کرد؟ یا میشه طوری نقشه رو ذره ذره کامل کرد که قابلیت حرکت رو درش داشته باشیم و بتونیم از بازخوردهای حرکتمون برای تکمیل ادامه نقشه کمک بگیریم؟ جواب میتونه مثبت باشه یا منفی. اما روح Agile جواب مثبت به این سوال میده. دقت کنید ما در اینجا خود نقشه مسیر هدفمون هست و نه اینکه انتهای نقشه کجاست! انتها هر کجا میتونه باشه. ما میخوایم کاری کنیم که با دانسته های فعلیمون بهترین نقشه رو مصور کنیم و تا اونجایی که مصور کردیم با موفقیت حرکت کنیم تا بهش برسیم. هدف این است نه صرفاً نقطه آخر نقشه.

اگر در بیانیه چابک هم دقت کنید خواهید دید که مواردی که ارزش کمتری دارن بیشتر به تهیه وتکمیل نقشه پیش از حرکت اشاره می کنن و مواردی که ارزش بالاتری دارن به شروع حرکت و تکمیل نقشه توام با حرکت دلالت دارن.  اما ممکنه این سوال به ذهن خطور کنه که  فریم ورک های دیگه هم به نقشه مسیر تقریباً همین نگاه رو داشتن حالا چرا اجایل؟ در جواب باید بگم که ذات Agile با این نگاه به نقشه بسیار همگون تر است تا روش های دیگه ی توسعه نرم افزار. ۴ ارزش بیانیه چابک و ۱۲ اصل Agile کاملاً در راستای همین نگاه است که به وضوح قابل مشاهده است.

یوزر اینترفیس به سبک اجایل #۲

{ ارسال شده در ۲۸ مرداد ۱۳۹۱ توسط حمیدرضا }
برچسب ها : , ,
مربوط به : توسعه وب

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

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

از آنجایی که معمولاً وظیفة طراحی UI بعهدة شخصی با عنوان Web Designer ،UI Designer و یا Front-end Developer هست بهترِ درابتدا ببینیم این شخص چه حیطه مسئولیتی داره. من قبلاً راجع به کلیات حرفه طراحی وب صحبت کردم ولی موارد ذیل شرح کامل‌تر مسئولیت‌های یک طراح واسط کاربری در یک تیم توسعه هست. البته شاید این نقش ها دارای کمی اختلاف با هم باشند ولی کلیاتشون همین ها هست:

  • Graphic UI Design
  • User Experience Design
  • Information Architecture
  • Front-end Development

ممکن ِ تا بحال فکر می‌کردیم که صرفاً یک طراح موارد اول و آخر رو باید انجام بده اما اون چیزی که یک توسعه دهنده واسط کاربری رو از دیگران متمایز می‌کنه میزان آشناییش با موارد ۲ و ۳ هست. مسلماً خیلی از برنامه‌ها رو دیدید که برای رسیدن به یه آیتم از منوهایی سر در میارید که اصلاً ارتباطی به هم ندارند بعبارت دیگه برنامه  نقشة مسیر خوبی نداره یا اسم آیتم‌ها طوری انتخاب شده که با کارِ اون آیتم سازگار نیست و … مواردی از این قبیل مثال های پیش پا افتاده ای از موارد ۲ و ۳ هستند که گاهی اوقات از موارد ۱ و ۴ مهم‌تر هستند. شاید در طراحی یک وب سایت ساده این موارد خیلی به چشم نیایند ولی در یک برنامه Enterprise با ۱۰۰۰ فرم و مدیریت فرآیندهای پیچیده از اهمیت ویژه‌ای برخوردار می‌شن. اما یک اینترفیس خوب چه ویژگی هایی باید داشته باشه؟

  1. تمیزی. یکی از مهمترین ویژگی‌های یک اینترفیس خوب هست. معمولاً با یک نگاه میشه فهمید این اینترفیس تمیز هست یا نه. Outlook نمونه اینترفیس تمیز و این لینک نمونة یک اینترفیس غیر تمیزاست.
  2. اختصار. خلاصه و مفید رو مسلماً شنیدید تا اونجایی که می‌شه در استفاده از آیتم‌ها، منوها، تصاویر و هر آنچه که با مخاطب ارتباط برقرار می‌کنه اختصار به خرج بدید. اختصار به این معنیست که اگر شما می‌تونید با دو تا حرف یا آیتم منظور رو برسونید دیگه نیازی نیست با ۱۰ تا مورد این کار رو انجام بدید. دقت کنید این اختصار منجر به عدم درک از موضوع نشه.
  3. آشنایی. مخاطب با دیدن Tab می‌دونه که باید روی هر آیتم کلیک کنه و به دلیل تجربه‌های قبلی با اینترفیس‌های دیگه کاملاً با عملکرد این کنترل آشناست. آیکون setting، print و save در تمام برنامه‌ها یکسان هست. از مواردی که مخاطب اصلاً هیچ آشنایی باهاش نداره کمتر استفاده کنید.
  4. پاسخگویی. سرعت برنامه برای کاربر خیلی مهمِ. خصوصاً در برنامه‌های تحت وب سرعت بارگذاری Front-end و Back-end تواماً مطرح است. شاید ضعف سرعت فقط در Back-end برنامه باشه ولی کاربر چیزی از کد پشت برنامه نمیدونه. روی یک دکمه کلیک کرده و همچنان Loading رو می‌بینه. نکته دیگه‌ای که در پاسخگویی باید انجام بگیره تعامل با کاربر هست. فرض کنید من یک فایل attach کردم اگر برنامه درصد آپلود فایل رو در هر لحظه به من بگه شرایط خیلی بهتر از این میشه که بعد از ۱۰ دقیقه من نمیدونم ۱ ساعت دیگه مونده یا یک دقیقه.
  5. جذابیت. مسلماً عوامل زیادی در جذابیت اینترفیس از ترکیب رنگ گرفته تا حتی کنترل‌ها تاثیرگذار هست. جذاب کردن اینترفیس کار حرفه‌ای ها است و در اینجا UX یا User Experience که از وظایف یک طراح واسط کاربری بود پر رنگ‌تر می‌شه. ذکر این نکته مهم است که در شکل گیری جذابیت، به نوع مخاطب حتماً باید توجه کرد. اگر شما برای یک مدرسه که کاربرانش دانش‌‌آموزان هستند یک برنامه می‌نویسید جذابیت رو از نگاه یک نوجوان ۱۴ ساله باید تعریف کنید.
  6. کارآیی. یک اینترفیس ابزاری است که شما رو از جایی به جایی دیگه می‌بره. از تهران تا اصفهان رو هم میشه با یک بنز S500 رفت هم با یک پراید. با هر دو هم با رعایت قوانین رانندگی در زمان برابر به مقصد می‌رسیم. اما کارآیی در اینجا لزوماً مدت زمان رسیدن به مقصد نیست، راحتی در سفر هم جزئی از کارایی وسیله نقلیه هست. مورد دوم و سوم در وظایف طراح واسط کاربری باعث افزایش کارآیی اینترفیس خواهد شد. مسلماً پیش اومده که بخواین یه عکس رو بک گراند موبایلتون بذارید و این تجربه در گوشی‌های مختلف مبین مقایسه بین کارآیی‌ گوشی‌های مختلف در انجام یک عملیات ثابت است. ذکر این نکته مهم است که کارآیی UI با کارآیی خود نرم افزار میتونه متفاوت باشه. بعنوان مثال وب سایت لینکدین جزء اون دسته از محصولات نرم افزاری شناخته شده است که علی رغم این که کارآیی موضوعی بالایی داره و با استقبال زیادی روبرو شده ولی متاسفانه کارآیی UI ضعیفی داره. همونطور که می بینید این اتفاق در یک پروژه حرفه ای هم احتمال وقوعش وجود داره. هرچه ابعاد پروژه بزرگ تر و پیچیده تر باشه مدیریت کارآیی UI هم مشکل تر می شه.

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

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

نحوه ساخت وب ستاپ در برنامه های ASP.NET

{ ارسال شده در ۱۹ مرداد ۱۳۹۱ توسط حمیدرضا }
برچسب ها : , , ,
مربوط به : توسعه وب

برنامه های تحت وب عموماً در اینترنت میزبانی میشن ولی ممکن هست که شما بخواین یک وب اپلیکیشن تجاری رو در محیط مشتری نصب کنید. مسلماً اولین چیزی که بواسطه معماری برنامه های وب ِمایکروسافت به ذهن میرسه استفاده از IIS هست. از طریق ایجاد یک ویرچوال دایرکتوری و باقی قضایا … بدیهی است که در این حالت نصب دیتابیس SQL می بایست در سرور انجام شه و تنظیمات کانکشن استرینگ رو هم اعمال کنید. اما با توجه به شیوه متداول نصب برنامه های ویندوزی شاید این سوال به ذهن برسه آیا میشه برای وب اپلیکیشن هم ستاپ ساخت؟ جواب این سوال مثبت هست بطوریکه ابزارهای زیادی هم تولید شده که این کار رو با امکانات بیشتری فراهم می کنه. اما در این پست من روشی رو می گم که با استفاده از امکانات ویژوال استادیو این کار قابل انجام هست. اصطلاحاً به این روش MSI Installer هم گفته میشه. روش کار ساده هست به این ترتیب که یک وب سایت ایجاد می کنیم، از طریق Microsoft Web Deployment برنامه رو precompile می کنیم و در آخر با استفاده ازWeb Setup خروجی MSI رو که همون ستاپ برنامه هست می گیریم. مراحل باختصار:

  • در ابتدا نیاز هست تا add-in مربوط به Web Deployment رو برای VS2010 از اینجا دانلود و نصب کنید. بعد یک وب سایت یا وب اپلیکیشن ایجاد کنید. به دلیل مزایایی که در merge فایل های dll در وب اپلیکیشن هست شاید انتخاب مناسب تری باشه.
  • سپس در Solution Explorer روی نام وب سایت کلیک راست و گزینه Add Web Deployment Project رو انتخاب کنید.  نام و مسیر رو وارد کنید.
  • در این مرحله می بایست Web Setup رو اضافه کنیم. برای این کار روی سولوشن پروژه در Solution Exp کلیک راست و Add New Project کنید سپس از قسمت سمت چپ از طریق Other Project Type/Setup and Deployment و انتخاب VS Installer می تونید به Web Setup Project برسید. اون رو انتخاب و OK کنید.
  • در Solution Explorer سه پروژه خواهید داشت: Web Site+ Web Deploy + Web Setup. روی Web Stup کلیک راست کرده و از طریق گزینه Add یک Project Output ایجاد کنید. دقت کنید در پنجره ای که باز می شود باید پروژه Web Deployment را انتخاب کنید. در واقع با این انتخاب خروجی Deployment محتوای Web Setup خواهد بود.
  • در مرحله بعد از سولوشن پروژه Properties بگیرید و گزینه Project Dependency رو انتخاب کنید. برای پروژه Setup باید هر دو چک رو بزنید. برای Deploy فقط پروژه Website و برای Website هیچ کدوم از چک ها نیازی نیست. فکر کنیم دلیلش هم واضح باشه. در واقع ترتیب build با توجه به وابستگی پروژه ها بهم مشخص میشه.
  • در مرحله بعد می رسیم به Configuration Manager. مجدداً از سولوشن پروژه پراپرتی بگیرید و کانفیگویشن رو انتخاب کنید. در حالت Release تمام پروژه ها باید Build شود و در حالت Debug فقط Website.
  • حالا پروژه رو Build کنید. در خروجی Build فایل exe رو مشاهده می کنید.

هدفم صرفاً آشنایی خوانندگان با این روش بود. مطالعه جزئی تر بعهده خودتون. اما ممکن است قبل از نصب، نیاز باشه بررسی کنه که ببینه دات نت فریم ورک یا حتی SQL Express نصب هست یا نه. برای این کار میتونید از پروژه Setup در سولوشن بار Property بگیرید و در قسمت Prerequisite تنظیمات لازم رو انجام بدید. اگر از این آیتم استفاده کردید حتماً Windows Installer رو هم  انتخاب کنید.

یوزر اینترفیس به سبک اجایل #۱

{ ارسال شده در ۱۴ مرداد ۱۳۹۱ توسط حمیدرضا }
برچسب ها : , ,
مربوط به : توسعه وب

چند روزی هست که مایکروسافت وب سایت outlook رو معرفی کرده که در واقع نسخه جدیدی از Hotmail هست. در بدو لاگین ظاهری تمیز، ساده و خلوتی رو می بینید که از جهاتی شبیه به اولین نسخه های جی میل به نظر میاد ولی به مراتب جذاب تر. کاربری فوق العاده ساده ای داره در عین حالی که به گرافیک وب هم توجه کرده. این تغییر نگرشِ اینترفیسی در وب سایت مایکروسافت، ویندوز ۸ و حتی در نسخه جدید آفیس هم کم و بیش دیده میشه و کاملاً به سمت حداقل پیچدگی + حداکثر کارایی داره پیش میره. در کل من از اینترفیسش خیلی خوشم اومد. یاد اینترفیس های نرم افزارهای وطنی افتادم و پیچدگی هایی که بر سر راه کاربر قرار داره طوری که با کلی کلاس آموزشی و داکیومنت و سی دی، باز هم مسلط نمیشه و جالبترش اینه که در تغییر ورژن یه دفعه همه چی عوض میشه و همون آش و همون کاسه… البته از حق نگذریم اینترفیس های خوب هم داریم ولی خوب ها خیلی کم هستند.

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

Microsoft Surface Tablet

{ ارسال شده در ۰۳ تیر ۱۳۹۱ توسط حمیدرضا }

بالاخره مایکروسافت به عرصه تولید تبلت ورود پیدا کرد. از اونجایی که این ورود توام با ارائه ویندوز ۸ بعنوان سیستم عامل این تبلت هست به نظر میاد با استقبال خیلی خوبی هم مواجه شه. about1۱۰٫۶ اینچ اسکرین این تبلت هست با وزن حدود ۹۰۰ گرم و در دومدل ۶۴GB و ۱۲۸GB. یه ورودی microSD داره و همچنین USB3.0. البته این تبلت با Windows RT هم ارائه میشه که در این حالت وزنش حدود ۶۷۶ گرم هست. در مورد CPU و RAM در فیچرلیست محصول در سایت مایکروسافت چیزی گفته نشده ولی سایت های دیگه ای سی پی یوی مدل ویندوز ۸ رو Intel Core i5 ذکر کردن. ظاهراً شروع قیمت نسخه ویندوز ۸ از ۹۹۹ دلار هست و نسخه دیگه از ۵۹۹ دلار. در مورد تاریخ رلیز هم اعلام رسمی صورت نگرفته ولی به نظر پاییز ۲۰۱۲ باشه. +

باور Agile

{ ارسال شده در ۳۱ خرداد ۱۳۹۱ توسط حمیدرضا }

یه روز صبح از خواب بلند میشم و به خودم میگم من میخوام از امروز سلامت تر زندگی کنم و تصمیم میگیرم هر روز یه سیب بخورم. حتماً اون ضرب المثل بلاد بیگانه رو شنیدید که میگه: An Apple a Day Keep Doctor Away.

Apple_download

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

این نکته در توسعه نرم افزار هم میتونه صادق باشه. شرکت یا سازمان شما تصمیم گرفته اجایل کار کنه، جلسات متعددی برگزار شده، بسترسازی های سازمانی! انجام شده و خیلی کارهای دیگه اما نکته مهم اینه که آیا به صرف گفتن اجایل و اسکرام کار کردن و برگزاری ۴ تا جلسه stand-up و داشتن رول های SM و PO میتونیم به نتیجه برسیم؟ آیا عادت های قدیمی ای که در توسعه نرم افزار داشتیم رو ترک کردیم؟ آیا مدیریت منابع انسانیمون مثل گذشته هست؟ آیا هنوز خودمون رو عالم دهر میدونیم و از هیچ کس مشورت نمی گیریم؟ آیا از مشارکت و همراهی افراد زیر مجموعه مون لذت می بریم و یا هنوز باور داریم که من رده سازمانیم از فلانی بالاتره. یک سازمان یا یک تیم زمانی Agile خواهد شد که علاوه بر اینکه اصول ۱۲ گانه اجایل رو درک کرده و بهشون باور قلبی داره، هر آنچه که با این اصول در نتاقض هست رو هم ترک کنه و نگرش خودش رو تغییر بده. تنها در این حالت هست که تفکر اجایل و متدهای وابسته ش میتونه در توسعه محصول موفق تاثیرگذار باشه.