مقاله‌ی جالبی از Tim O’Reilly در مورد نسل بعدی نرم‌افزارها مطالعه کردم که ضمن آوردن آدرس آن، خلاصه‌ای از آن را نيز در زير آورده‌ام.

وی در مقاله خود آورده که سعی کرديم ابتدا با مثال تفاوت وب 1.0 و وب 2.0 را حس کنیم:

در ادامه سعی کرده است با استفاده از تجارب مؤفق، به بیان ويژگی‌های وب 2.0 بپردازد:

1- وب به عنوان يک پلتفرم
نرم‌افزار به عنوان يک سرويس در وب مورد استفاده قرار خواهد گرفت بر خلاف کامپیوترهای دسکتاپ (مانند گوگل)

2- استفاده از خرد جمعی
اطلاعات جمعی از افراد متعدد به جای تعداد قلیلی از متخصصان (استفاده از خیل عظیمی از بازنگرها در انجمنهای شرکت آمازون برای بازنگری کتابها)
3- داده به عنوان “Intel Inside” بعدی
مالکیت بانکهای داده خاص مانند بانک اطلاعات محصول شرکت آمازون)
4- پایان چرخه ارائه نسخه نرم‌افزار
فرکانس بالای ارائه نسخه جدید نرم‌افزار (شرکت فليکر هر يک و نیم ساعت، يک نسخه جدید ارائه می‌دهد)
5-مدلهای برنامه‌نويسی سبک وزن
محيطهای ساده توليد که به راحتی امکان بازبه‌کارگیری را برای مشتریان فراهم می‌کند.
6-نرم‌افزار بالاتر از سطح یک وسیله جانبی
بسیاری از وسایل جانبی از طریق وب با هم کار می‌کنند (مانند iTunes و iPod)
7-تجارب کاربری غنی و توانا
واسط کاربری پويا که فاصله بین استفاده کنندگان وب و دسکتاپ را کاهش می‌دهند.

آدرس مقاله:

What Is Web 2.0
Design Patterns and Business Models for the Next Generation of Software

داشتم مصاحبه با گریدی بوچ(Grady Booch)را می‏خواندم. مصاحبه‌کننده سئوالات جالبی پرسیده بود و از این رو کمک می‌کرد تا با دیدگاه این صاحب‌نظر دنیای مهندسی نرم‌افزار بیشتر آشنا شوم.
مدلسازی یکپارچه سیستم (سخت‌افزار و نرم‌افزار)(Unified System Modeling)، پارادایم آینده زبانهای برنامه‌نویسی، تبدیل تجریدهای سطح بالا به مدلهای سطح پايين‌تر، نقدهای وارد به بازبه‌کارگيری، خلاصه تجربه وی در انتخاب موضوعات مهم پروژه نرم‌افزاری، آينده UML، بهترین تجارب در نوآوری حوزه مهندسی نرم‌افزار، اکسیر حیات فرآیند تولید نرم‏افزار(Holy Grail Software Process)، توصيه وی به دست‌اندرکاران صنعت نرم‌افزار از مهم‌ترين سئوالات بود.

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

Frontier Journal: What’s your career advice for people who work in software industry؟
Grady Booch: Being a software developer is both a privilege and a responsibility. In this field, there are so many places to grow and contribute. Learn by studying the work of others; follow your passion. Most of all, be sure you have fun in the process.

همیشه تغییرات تکنولوژی، آن هم با این سرعت، کمی ! آشفتگی ایجاد می‌کند به خصوص وقتی در جایگاهی هستید که یاتصمیم‌سازی می‌کنید و یا تصمیم‌گیری. وجود frameworkها برای ایجاد لایه‌ای از تجرید روی تکنولوژی است که شما با آن کار می‌کنید. مثلاً در پلتفرمهای مایکروسافتی، دات نت، لایه‌ای است روی خیلی‌ از تکنولوژی‌های مایکروسافتکه شما با به‌کارگیری آنبه سطح تجرید بیشتری نسبت به محیط اجرای نرم‌افزار دست پیدا خواهید کرد و از این رو تغییرات محیطی کمتر روی نرم‌افزار شما تأثیر خواهند داشت. اما نکته این است که اگر خود این تجریدها، محل تغییر باشند، چه خواهد شد.

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

Should you skip .NET 2.0 altogether?

منتظر نظراتتان هستم.

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

حاضران عبارتند بودند از:

– خانم مهندس صبا بزرگی

– خانم مهندس نیوشا قریشی

– خانم مهندس حمیده مطهریان

– آقای مهندس علیرضا خیرخواه

در جلسه سوم، چون کارهایم را انجام نداده‌ بودم، داوطلبانه دوستان را شیرینی مهمان کردم. هفته پیش هم چون علیرضا در جلسه اول غائب بود، همه را به شیرینی مهمان کرد.

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

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

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

دوست خوبمان، آقای مهدی جلالی که هنوز موفق به دیدارشان نشده‌ام، نوشته بودند: “از شما دعوت می شود با وبسایت www.uml.ir جهت ايجاد پایگاه رسمي منابع و مفاهيم تحلیل سیستم شیء گرا با ما همکاری کنید. “، ضمن تشکر باید عرض کنم که هدف من فعالیت رسمی در این حوزه نیست و ازاین رو نمی‌توانم خدمت دوستان خوبم باشم.این وبلاگ را هم برای دلخوشی خودم شروع کرده‌ام و ناگفته خود پیداست که به دلیل مشغله نمی‌توانم آن طور که دلم می‌خواهد آن رافعال کنم و مطالب مورد علاقه‌ام را در آن قرار دهم . در این جااز قول مهندس خیرخواه که ایشان نیز از قول مهندس یگانگی گفتند که شما وقتی سایتی را راه‌اندازی می‌کنید، به خواننده متعهد هستید. این بزرگترین مشکلی است که من با آن روبرو هستم. قبول مسئولیت کار راحتی است، اما عشق آسان نمود اول، ولی ….

یکی دیگر از دوستان به نام علی نوشته بودند که در مورد Agile Methods توضیح بدهم که انشاءاللهبه زودی در این مورد در حد بضاعتم خواهم نوشت.

یکی دیگر از خوانندگان فرمودهبودند که در مورد مدل 4+1 دیدمعماری فیلیپ کراچن توضیح بدهم و خانم حمیده هم فرموده بودند که مطالب معماری را ادامه بدهم، که حتماً این کار راادامه خواهم داد.

از آقای مهندس علی نوبر هم کمال تشکر را دارم و خدمتشان عرض می‌کنم که مفهوم Validation با آنچه در پوکایوکه آمده متفاوت است.ایده من ازپوکایوکه این است که ما از این تکنیک درمهندسی نرم‌افزاربدینشکل می‌توانیم استفاده کنیم که کاربر (در محصول نرم‌افزاری) و نیز توسعه‌دهنده (در فرآيند تولید نرم‌افزاری) نتواند اشتباه کند. مثلاًتوسعه‌دهنده نتواند دراستفاده از مؤلفه امنیت در طراحی و پیاده‌سازی اشتباه کند. (فرض کنید که واسطهای-interface- مؤلفه-component- مانندشاخکهایسه‌شاخه تلفنباشد که نگذارد در پریز برق وارد شود.) – چقدر خوب می‌شد که من و آقای نوبر به همراه اساتید و دانشجویانی تیمی تشکیل می‌دادیم و روی این موضوع کار می‌کردیم.

به سرکار خانم صادقی هم عرض می‌کنم که انشاءالله در مورد ITO Seeding بیشتر خواهم نوشت.

نکته آخر این که آقای مهندس هادی از دوستان عزیز و دوست‌داشتنی‌ام است. ایشان به من فرموده‌ بودند که نمی‌توانند روزهای زوج برای جلسات نشریه تشریف بیاورند و از آنجا که برای بنده مقدور نبود که روزهای فرد در جلسات نشریه باشم و از طرفی به دلیل تشکیل جلسات در شرکت مدار گسترش فناوری حضور من الزامی بود، از این رو قرار شد که من هماهنگی جلسات را به عهده داشته باشم و ایشان را مطلع نمایم. لذا غیبت ایشان موجه است. اما چون خیلی به ایشان ارادت دارم، هر چند وقت یک بار، سر به سر ایشان خواهم گذاشت. هر چند عرض کنم که ایشان مدتهاست که هیچ تماسی در مورد نشریه با من نگرفته و حتی در mailing list نشریه هم غیرفعال هستند. خانم مهندس بزرگی که زحمت هماهنگی‌ها را به عهده دارند، گواه مطلب اخیر خواهند بود.

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

چند وقت پیش دنبال موضوعی می‌‌گشتم که با نمونه دیگری از این گونه روباتها که اتفاقاً از روی آلیس ساخته شده بود، آشنا شدم با این تفاوت که دوست جدید ما، می‌توانست در مورد UML با شما به گفتگو بپردازد. این روبات که سایبر ایوار (Cyber Ivar) نام دارد و نامش از نام ایوار جیکابسون (Ivar Jacobson) -این پیرمرد خستگی ناپذیر- اقتباس شده است، ویژگیهای جالبی دارد. من چند سئوال از دوستمان پرسیدم و جوابهایی که داد، جالب بود.

به شما هم توصیه می‌کنم که یک بار صحبت با دوست تازه آشنایمان را تجربه کنید.

کتاب پوکا یوکه تکنیک خطاناپذيرسازی فرآيندها تأليف مايکل آر. بيوریگارد، ریموند جی.میکولاک، رابین ای مک درموت و ترجمه مهندس سارا صلواتی کتاب جالبی است. این کتاب را از حسین هدیه گرفتم و چه هدیه باارزشی. بخش‌هایی از کتاب را در زیر آورده‌ام:
“در لغت‌نامه ژاپنی، پوکایوکه به معنی حماقت‌ناپذيری ترجمه شده بود و لیکن به تشخیص اساتید من، … ترجمه آن را خطاناپذيری نامیدند.
پس از بازگشت به آمریکا متوجه شدم که اکثر شرکتهای ما نیز ازخطاناپذيری فقط در همان زمینه (یعنی به عنوان ابزار ایمنی) استفاده می‌کنند و خطاناپذيرسازی در زمنیه بهبود تولید و بهره‌وری کاربردی ندارد. درحالیکه امروزه استفاده از این تکنیک تغییر کرده و من از اینکه می‌بینم خطاناپذيرسازی در جریان اصلی بهبود فرآيند کاربرد پیدا کرده است، خوشحالم.
به نظر من، موفقیت نصیب کسانی خواهد شد که روشهای خطاناپذيرسازی را در درازمدت دنبال کنند.
خطاناپذیرسازی روشی جهت غیرممکن ساختن اشتباهات است. این تکنیک می‌تواند با ایجاد تغییرات دائمی در تجهیزات، عملیات و یا رویه‌ها، فرصت بروز اشتباهات را حذف یا در صورت بروز یک اشتباه، با ارسال سیگنال، سریعاً جلوی انجام کار اشتباه را بگيرد.
تمرکز تکنیک خطاناپذیرسازی بر سلب فاکتورهای انسانی در مواقعی است که انجام کاری بر اثر تکراری بودن آن نیاز به حافظه، توجه و تمرکز دارد. البته این بدان معنی نیست که فکرکردن را در انجام کارها حذف کنیم، بلکه باید کاری کرد که زمان و ذهن افراد آزاد شده، با انجام یک سیستم خلاق و یک فعالیت ارزش‌آفرين(Value Adding) کارها بدون ترس از اشتباه بودن آنها و به صورتی صحیح انجام شوند.
مطمئناً اغلب اشتباهات به طور عمدی ایجاد نمی‌شوند، آنها معمولاً بر اثر پيچيدگی فرآيندها ایجاد می‌شوند.
در زمینه بروز اشتباهات، دو طرز تفکر متفاوت وجود دارد:
1- اشتباهات اجتناب ناپذیرند و شما باید بیاموزید که چگونه با آنها زندگی کنید. این طرز تفکر موجب کاهش بهره‌وری شده و همیشه ما را به سوی شکست سوق می‌دهد.
2- اشتباهات می‌توانند و باید حذف شوند. اگر چه این طرز تفکر به تنهایی چاره‌ساز نیست و لیکن زمینه‌ساز فعالیتهای بعدی جهت دستیابی به محصولات با عیوب صفر است.
نمونه‌هایی از خطاناپذیرسازی در زندگی روزمره:
1-اغلب اتوها در صورت عدم استفاده از آنها به طور خودکار خاموش می‌شوند.
2-نوارهای صوتی-تصویری و دیسکتهای کامپیوتر که با برداشتن زبانه ایمنی آنها از پاک شدن و یا ضبط مجدد بر روی آنها جلوگیری می‌شود.
3-دیسکتهای کامپیوتری را نمی‌توان به صورت اشتباه وارد درایو نمود. “

مطالعه این کتاب باعث شد که خیلی در مورد به کارگيری این روش در تولید نرم‌افزار فکر کنم.
ما از دو سو با فرآيند درگیر هستیم.
اول: در تولید نرم‌افزار همه ما از یک فرآيند و روش استفاده می‌کنیم. منظورم از روش، روشهايی مانند RUP، Agile، … نیست. بلکه گامهای انجام کار تولید نرم‌افزار است.
دوم:در اکثر قریب به اتفاق نرم‌افزارهايی که تولید می‌کنیم، روش و فرآيند انجام کار مشتری را مکانیزه و گاه دستخوش تغییر می‎‌‌کنیم.
اگر بتوانیم این ایده و تکنیک را در این دو مقوله به کار بگیریم، شاید بتوانیم درصد اشتباهات را کاهش دهیم، اشتباهات حین تولیدمان و اشتباهات کاربر محصولمان.
یک مجموعه از ایده‌ها در ذهنم است ولی هنوز پخته نیست.
اگر شما هم نمونه‌ها و يا ايده‌هايی در این زمینه دارید، برایم یادداشت بگذارید.