همه نوشته‌ها

۱۰ اصل برای داشتن یک رابط کاربری خوب

۱۰ اصل برای داشتن یک رابط کاربری خوب

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

آگاهی امنیتی : چگونگی بدست آوردن کلمه عبور Application Pool های IIS

آگاهی امنیتی : چگونگی بدست آوردن کلمه عبور Application Pool های IIS

این نوشته را در دسته‌بندی برنامه‌نویسی شیرپوینت قرار دادم چرا که بیشترین زمانی که با Application Pool ها سر و کار داشتم زمان نصب و تنظیم شیرپوینت بوده است. کد اصلی مربوط به نوشته آقای Sahil Malikاست. در شیرپوینت ۲۰۰۷ می‌توانستیم با استفاده از SPApplicationPool.Password کلمه عبور Application Pool را بدست آوریم که در نسخه‌های بعدی دیگر استفاده نمی‌شود. برنامه‌ای به نام appcmd در آدرس c:\windows\system32\inetsrv وجود دارد که با استفاده از دستور زیر کلمه عبور Application Pool را به شما نمایش می‌دهد.

(تقریباً) همه چیزی که درباره Windows Azure باید بدانید

(تقریباً) همه چیزی که درباره Windows Azure باید بدانید

ویندوز آژور و آرایه سال گذشته و پس از طی مراحل مشکلی (البته مشکل به خاطر ایرانی بودن) این امکان را یافتیم تا خدمات Azure مایکروسافت را آزمایش کنیم. این نوشته که به صورت پرسش و پاسخ است، نگاهی دارد به امکانات Azure. این نوشته با پرسش‌های شما تکمیل خواهد شد. می‌توانید در بخش نظرات پرسش‌های خود را در خصوص Azure مطرح کنید. در نگارش این مطلب، از نوشته اسکات هنسلمن که به مبحث قیمت‌های آژور می‌پردازد نیز استفاده شده است.

۳۰ روز با TDD: روز پانزدهم - ساده همیشه به معنی واضح نیست قسمت دوم

۳۰ روز با TDD: روز پانزدهم - ساده همیشه به معنی واضح نیست قسمت دوم

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

۳۰ روز با TDD: روز چهاردهم - ساده همیشه به معنی واضح نیست قسمت اول

۳۰ روز با TDD: روز چهاردهم - ساده همیشه به معنی واضح نیست قسمت اول

در نوشته‌های قبلی دیدیم که چطور با استفاده از stub ها کد کلاسی وابسته زیر تست را mock کردیم. نوشته انگلیسی روز چهاردهم را در این آدرس می‌توانید مطالعه کنید. یک روز دیگر، یک تست دیگر برای این نوشته نیز مثال فروشگاه مطالب قبلی را ادامه می‌دهیم. تست بعدی زمانی است که کاربر یک آیتم را سفارش می‌دهد و تعداد سفارش صفر است و InvalidOrderException باید throw شود. در ظاهر این یک تست ساده به نظر می‌رسد: هر سفارش لیستی از آیتم‌ها دارد اگر تعداد هر یک از آیتم‌ها برابر صفر بود یک exception را throw‌ کن.

۳۰ روز با TDD: روز سیزدهم - ویژگی‌های بیشتر stub

۳۰ روز با TDD: روز سیزدهم - ویژگی‌های بیشتر stub

در روز دوازدهم با stub ها آشنا شدیم. نوشته روز سیزدهم به زبان انگلیسی را در این آدرس می‌توانید مطالعه کنید. زمان بازبینی کد من دوست دارم به صورت متناوب با تیم برای بازبینی کدها جلسه داشته باشم. بعضی تیم‌ها زمان‌های برنامه‌ریزی شده برای این کار دارند و بعضی ندارند. یکی از چیزهایی که دوست دارم پایه اصلی جلسات بازبینی کد باشد، بخش‌های مهم برنامه هستند که یا پیجیده‌اند یا بخش‌های زیاد دیگری با آن‌ها در ارتباطند.

۳۰ روز با TDD: روز دوازدهم - کار با Stub ها

۳۰ روز با TDD: روز دوازدهم - کار با Stub ها

نوشته به زبان انگلیسی روز دوازدهم را در این آدرس می‌توانید مطالعه کنید. در نوشته قبلی این سری یک پروتوتایپ از اینکه PlaceOrder برای یک OrderService در یک برنامه e-commerce چطور باید باشد به شما نشان دادم. برای نمایش mocking ما یک نسخه کاربردی از این منطق تجاری (business logic) را با TDD پیاده‌سازی خواهیم کرد. این به آن معنی است که با یک نیازمندی تجاری شروع می‌کنیم: تصور کنید که کاربر به برنامه وارد شده (login کرده است) و آیتم‌هایی را در سبد خرید قرار داده است.

ساختار تیم‌های مدرن نرم‌افزاری قسمت پنجم: جلسات نرم‌افزاری

ساختار تیم‌های مدرن نرم‌افزاری قسمت پنجم: جلسات نرم‌افزاری

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

چطور برای شیرپوینت وب پارت بنویسیم؟ قسمت اول: سلام دنیا

چطور برای شیرپوینت وب پارت بنویسیم؟ قسمت اول: سلام دنیا

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

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

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

حکایت ۱۰۰ نفر اول اپل اپل شرکت بزرگی است. نیروی کار شرکت‌های بزرگ مدام در حال کم و زیاد شدن هستند. در ابتدای فصل سی کتاب زندگینامه جابز درباره ۱۰۰ نفر اول اینطور می‌خوانیم: … جابز سالی یک بار، ارزشمندترین کارمندان اپل را به تفرجی می‌برد که “۱۰۰ نفر اول” نام داشت. انتخاب بر اساس یک راهبرد ساده انجام می‌شد: اگر مجبور بودی فقط ۱۰۰ نفر را با خودت سوار قایق نجات کنی و به شرکت بعدی ببری، چه کسانی را انتخاب می‌کردی؟او در پایان هر تفرج، جلوی یک وایت‌بورد می‌ایستاد و می‌پرسید: ۱۰ پروژه بعدی که باید انجام دهیم چیست؟ افراد برای این که پیشنهادشان در فهرست قرار بگیرد می‌جنگیدند.

۳۰ روز با TDD: روز یازدهم - درباره Mocking

۳۰ روز با TDD: روز یازدهم - درباره Mocking

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

رفع خطاهای معمول و تکمیل راه‌اندازی Build Server برای TFS 2013

رفع خطاهای معمول و تکمیل راه‌اندازی Build Server برای TFS 2013

Build به کمک TFS اگر سری نوشته‌های تست جوئل را دنبال کرده باشید، حتماً درباره اهمیت build روزانهخوانده‌اید. برای داشتن یک روال build خوب ابتدا باید یک build serer داشته باشید. خوشبختانه TFS به خصوص در نسخه‌های جدید، کار build را برای پروژه‌های تیمی بسیار ساده کرده است. در این نوشته درباره خطاهایی که پس از نصب سرویس build در TFS ممکن است با آن‌ها برخورد داشته باشید و راه حل آن‌ها صحبت می‌کنیم.

توسعه ترس محور یا Fear Driven Development چیست؟

توسعه ترس محور یا Fear Driven Development چیست؟

توسعه ترس محور روز گذشته اسکات هنسلمن نوشته‌ای رو در وبلاگش منتشر کرد و از ترس‌هایی که تبدیل به یک روال توسعه نرم‌افزار می‌شوند گفت. او نام توسعه ترس محوریا Fear Driven Developmentرا برای این موضوع انتخاب کرده. شما هم در نظرات این نوشته از تجربیات خودتان درباره کار به روش ترس محور بگویید ترس سازمانی ترس سازمانی باعث می‌شود که برنامه‌نویس‌ها نگران اشتباه کردن، شکستن build یا ایجاد باگ‌های بشوند و سازمان را مشغول تمرکز بیشتر بر تولید کاغذ یا ایجاد بیش از حد پروسه‌ها و روال‌ها و خلاصه ایستادن در راه نوشتن کد.

گزارش آماری از دستمزد برنامه‌نویسان و طراحان وب در ایران

گزارش آماری از دستمزد برنامه‌نویسان و طراحان وب در ایران

گزارش آماری حقوق و دستمزد سال ۱۳۹۲ سایت ایران تلنت، گزارش جالبی را منتشر کرده و در آن حقوق و دستمزد متخصصان و مدیران ایرانی در ۲۳ گروه شغلی از جمله گروه کامپیوتر را ارزیابی و از نظر آماری نتایج آن را اعلام کرده است. در این نوشته، بخش‌هایی که مرتبط با دستمزد برنامه‌نویسان و طراحان وب است را بررسی می‌کنیم و در نوشته دیگری به تحلیل این دستمزدها خواهیم پرداخت.

۳۰ روز با TDD: روز دهم - بررسی بیشتر Refactoring‌ و NUnit

۳۰ روز با TDD: روز دهم - بررسی بیشتر Refactoring‌ و NUnit

در نوشته روز نهم، درباره Refactoring صحبت کردیم، نوشته به زبان انگلیسی روز دهم را در این آدرس می‌توانید مطالعه کنید. در روز دهم با امکانات بیشتری در NUnit و همچنین Refactoring آشنا خواهیم شد. بهترین شمشیرها از هر دو طرف می‌برند نه تنها مهم است که به صورت دوره‌ای کد business logic خودمان را refactor کنیم، بلکه لازم است به صورت دوره‌ای تست‌ها را نیز بررسی کنیم. به یاد داشته باشید که تست‌ها هم نوعی کد هستند و نیازمند نگهداری مشابه.