همه نوشته‌ها

ساختار تیم‌های مدرن نرم‌افزاری قسمت ششم: ارتباط با مشتریان

ساختار تیم‌های مدرن نرم‌افزاری قسمت ششم: ارتباط با مشتریان

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

۳۰ روز با TDD: روز هجدهم - بازبینی Refactoring قسمت اول

۳۰ روز با TDD: روز هجدهم - بازبینی Refactoring قسمت اول

توجه: قبل از این نوشته، آزمون‌های واحد (Unit testها) مربوط به تغییرات PlaceOrder نوشته قبلی را از اینجا می‌توانید دانلود کنید. در چند نوشته گذشته، متد PlaceOrder را از OrderService بیرون بردیم. برای مرور، متد فعلی این شکلی است: این متد کمی طولانی شده و همچنین داریم به محدوده نقض Single Responsibility Principel (برای مرور SRP روز پنجم را مطالعه کنید) وارد می‌شویم. در حال حاضر شش دلیل برای اینکه این متد باید تغییر کند شمردم:

«پریدن تیک» یا وقتی یک «نرم افزار» برای کشور مشکل ایجاد می‌کند

«پریدن تیک» یا وقتی یک «نرم افزار» برای کشور مشکل ایجاد می‌کند

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

۳۰ روز با TDD: روز هفدهم-تعیین ترتیب اجرا در mock ها

۳۰ روز با TDD: روز هفدهم-تعیین ترتیب اجرا در mock ها

امروز هم توسعه برنامه فروشگاهی که به روش TDD نوشتیم را با نگاهی نزدیک‌تر به سرویس Order Fulfillment که یک سرویس خارج از برنامه اصلی است، ادامه می‌دهیم. ارسال سفارش اگر نوشته قبلی را خوانده باشید، به یاد دارید که ما با یک سرویس خارج از برنامه اصلی برای اجرای سفارشات کار می‌کردیم. آن‌ها یک API فراهم کرده‌اند و ما OrderFulfillmentService را فراخوانی می‌کنیم. interface این API چندین فراخوانی و مجموعه‌ای از قوانین برای ترتیب فراخوانی‌ها دارد.

صادرات نرم‌افزار و خدمات نرم‌افزاری: خوب، بد، زشت

صادرات نرم‌افزار و خدمات نرم‌افزاری: خوب، بد، زشت

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

۳۰ روز با TDD: روز شانزدهم- استفاده از پارامترهای مشخص در Stub ها

۳۰ روز با TDD: روز شانزدهم- استفاده از پارامترهای مشخص در Stub ها

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

چطور (تقریباً) هر چیزی را در git به حالت قبلی برگردانیم؟ قسمت اول

چطور (تقریباً) هر چیزی را در git به حالت قبلی برگردانیم؟ قسمت اول

این نوشته ترجمه خلاصه شده‌ای است از How to undo (almost) anything with Git که در وبلاگ گیت‌هاب انتشار یافته است و از سهیل رشیدی برای معرفی آن در خبرنامه iDevCenter تشکر می‌کنیم. undo کردن تغییر عمومی (Public) سناریو:شما از دستورgit push استفاده کردید و تغییرات را به گیت‌هاب فرستادید و حالا متوجه شدید که یکی از commit ها مشکلی دارد، می‌خواهید آن commit را undo کنید. دستور Undo:برای سناریو بالا از دستور زیر استفاده کنید:

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

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

یک قول قدیمی وقتی درباره تست جوئل می‌نوشتم، در توضیحات مربوط به کاربردپذیری راهرویی قول دادم که درباره مواردی که به ایجاد یک 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 کرده است) و آیتم‌هایی را در سبد خرید قرار داده است.

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

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

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