امروز نامه ­ای دریافت کردم از یکی از دانشجویان قدیمی. متن نامه بدین شرح است:

«سلام بر اساتید عزیز،
غرض از مزاحمت تشکر بود از همگی شما. اخیرا من اینجا (ونکوور) مصاحبه ی کاری داشتم و در حین مصاحبه، غیر از همه ی چیزهایی که توی کلاس های مختلف شما یاد گرفته بودم، خیلی از پروژه هایی که توی درس ها نوشته بودیم هم کلی کمکم کرد. پروژه های درس برنامه سازی پیشرفته، فایل، دیتابیس، مهندسی اینترنت، شبکه، مهندسی نرم، شی گرایی، …. هر کدومشون یه جور کمک کرد. حتی پروژه ی فایل که فکر نمیکردم هیچ وقت به کارم بیاد 😉 جدی جا داشت که یه تشکر رسمی از همه شما بکنم.

خیلی خیلی متشکر به خاطر همش. هم از شما و هم از TA ها.
به امید اینکه روال درس ها در … همین جوری ادامه پیدا کنه.
خوب و خوش باشین،

….»

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

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

گزیده:
وای بر شاگردی که روزی بالاتر از استاد نشود.
داوینچی
(به نقل از آقای نگاهی)

نوروز فرخنده باد.

با بهترین آرزوها،

مهرداد

نوروز فرخنده باد.

با بهترین آرزوها،

مهرداد

حدود یک ماه پیش، بیستم بهمن­ماه، از آقای مهندس امراللهی (www.saeedamrollahi.com) خواهش کردم که افتخار دهند تا دقایقی در خدمتشان باشیم. ایشان نیز لطف کردند و دعوت ما را (حسین و من) پذیرا شدند. این دعوت هم برای تازه شدن دیدارها بود و هم به بهانه چاپ گزارش حضور ایشان در همایش کمیته استانداردسازی ++C در سوئیس در گزارش کامپیوتر شماره 194 (www.isi.org.ir) بود. ایشان اولین و تنها نماینده از ایران دراین نشستها بوده­اند و اولین حضور ایشان در سال 2009 و در فرانکفورت بوده است. ناگفته نماند که در گذشته ایرانیانی به نمایندگی از سایر کشورها در این سمینار حاضر بودند.

او آن چنان شیفته ++C است که ترجیح می­دهم وی را ++Mr. C (مستر سی پی پی) بنامم، نامی که برازنده دانش وسیع و تجارب گران­بار وی در این زبان است.

بخش کوچکی از گفت و گوی آن جلسه را در ادامه آورده­ام. امیدوارم که مفید باشد.

– سال 1380 ایمیلی به آقای استراستروپ نوشتم و سه پرسش از ایشان پرسیدم. انتظار نداشتم که پاسخ دهد، ولی با تعجب پاسخم را داد.

– اولین بار که سعی کردم در همایش شرکت کنم به دلیل دریافت­نکردن ویزا مؤفق نشدم. استراستروپ همان روز طی نامه­ای تأسف خود را از این موضوع به اطلاعم رساند.

– در گذشته ایمیل­هایم را دیر به دیر می­خواندم و پاسخ می­دادم. ارتباط با اعضای کمیته استانداردسازی و مقید بودن آنان به پاسخ­گویی ایمیل­هایشان باعث شده تا سعی ­کنم در زودترین زمان ممکن به نامه­هایم پاسخ دهم.

– بسیار رک هستند، در عین حال احترام همدیگر را نگه می­دارند.

– آن چه که یاد گرفتم عبارتند از: صبر و حوصله داشتن، احترام به رأی افراد

– کلیدواژه(keyword) جدید اضافه کردن به زبان کار دشواری است، چرا که باید کلمه­ای انتخاب شود که در تمامی کدهای نوشته­شده تا آن زمان وجود نداشته باشد.

– ما چوب اعتماد به نفس نداشتن را می­خوریم. آموختم که منفعل بودن خیلی چیز بدی است.

– هنگام شام، دربارة موضوعات مختلف صحبت می­کنند مثلاً یکبار حدود یک ساعت در مورد کشتی جنگی صبحت کردند، صحبت­های مستدل و گسترده! درحقیقت باید گفت که دانش عمومی آنها عمدتاً بالا است.

– حدود یک سال است که ارائه­ای آماده کرده­ام در مورد فرآیند استانداردسازی زبان ++C و چندین بار از مؤسسه استاندارد خواسته­ام که این مطالب را به آن­ها ارائه دهم، علاقه­ای نشان نداده­اند.

– هر ترم سمیناری دربارة ++C در دانشگاه شهید بهشتی ارائه می­کنم. (خیلی مفید )

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

گزیده:

اگر برگردم، رشته­ام را تغییر نخواهم داد. نرم­افزار رشته خوبی است. سعید امراللهی

چند وقت پیش یکی از مدیران عزیزم که وی را از این پس آقای مدیر خواهم خواند از من پرسیدند که شما در فیس بوک هستید؟ عرض کردم خیر و ادامه دادم که علاقه چندانی به عضویت در آن ندارم.

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

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

۱- خیلی شاد شدم چرا که بسیاری از دوستانم را که سالها از آنها بی خبر بودم، یافتم.

۲- ناراحت هم شدم چرا که دلم خیلی برایشان تنگ شد و احساس دلتنگی شدیدی می کردم.

۳- خنده دارترین بخش موضوع هم این بود که یکی از اعضای فیس بوک را یافتم که دارای نام و نام خانوداگی مشابه من بود فقط با قیافه متفاوت .

۴- موضوع جالب هم این که آقای مدیر شب همان روزی که به فیس بوک پیوستم تماس گرفت و گفت یک نفر با مشخصات شما برایم در فیس بوک درخواست فرستاده است. چون گفته بودید که علاقه ای ندارید که در فیس بوک باشید، نگران شدم که نکند کسی از مشخصات شما سوءاستفاده کند. ضمن تشکر از این همه احساس مسئولیت، خدمتشان عرض کردم که تصمیم گرفته ام کمی جوانگرایی کنم

گزیده:
زندگی به تلاشهایتان پاداش می دهد نه به بهانه هایتان.
اندرو متیو، ۵۱۳ درس زندگی، سام زالی

سيبِل: شما براي طراحي نرم‌افزار چه فرايندي را طي مي‌كنيد؟ آيا Emacs را به كار مي‌گيريد و شروع به نوشتن كد مي‌كنيد و سپس آن‌ها را جابجا مي‌كنيد تا درست به نظر برسند؟ يا آن كه مداد و كاغذ به دست مي‌گيريد و روي يك مبل راحتي مي‌نشينيد؟

جاشوا بلاك: چند سال پيش در OOPSLA يك سخنراني داشتم به عنوان «چگونه يك API (رابط برنامه كاربردي) خوب طراحي كنيم و چرا اين كار اهميت دارد» كه نسخه‌هاي گوناگوني از آن در وب وجود دارد. در آنجا به طور مفصل پاسخ اين سوال شما را داده‌ام.
مهم‌ترين چيز اين است كه بدانيد چه جيزي مي‌خواهيد بسازيد. به عبارت ديگر، چه مسأله‌اي را مي‌خواهيد حل كنيد. از اهميت تحليل نيازها [تحليل نيازمندي‌ها يا requirement analysis] به هيچوجه نبايد غافل شد. بعضي‌ها فكر مي‌كنند تحليل نيازها يعني اين كه شما پيش مشتري مي‌رويد و از او مي‌پرسيد چه مي‌خواهي؟ و او هم به شما مي‌گويد كه چه مي‌خواهد و كار تمام مي‌شود.
اما اين يك خيال باطل است. اين كار نه تنها به مذاكره و مصالحه نياز دارد بلكه يك فرايند درك متقابل است. بسياري از مشتريان به شما نمي‌گويند مسأله چيست بلكه راه حل را به شما مي‌گويند. مثلاً يك مشتري ممكن است به شما بگويد «من مي‌خواهم كه شما اين ويژگي‌ها را به سيستم بيفزاييد.» شما بايد بپرسيد «چرا؟ با اين سيستم چكار مي‌خواهيد بكنيد؟» و پرسش‌هايي شبيه اين‌ها. بايد آنقدر عقب و جلو برويد تا بفهميد مشتري واقعاً مي‌خواهد نرم‌افزار چه كاري برايش بكند. اين‌ها كارخواست‌ها [مورد كاربرد يا use case] هستند.
به دست آوردن مجموعه خوبي از كارخواست‌ها [موردهاي كاربرد]، مهم‌ترين كاري است كه در اين مرحله مي‌توانيد بكنيد. پس از آن كه اين كار را انجام داديد، محكي در دست داريد كه با آن مي‌توانيد هر راه حلي را بسنجيد. هر چقدر كه براي انجام صحيح اين مرحله وقت بگذاريد اشكالي ندارد زيرا اگر در اين مرحله دچار اشتباه شويد، ديگر كار تمام است و بقية فرايند توليد نرم‌افزار، در واقع وقت تلف كردن بيهوده است.
منبع: برنامه‌نويسان در حال كار، قسمت ششم، نوشته پيتر سيبِل، ترجمه استاد ابراهيم نقيب‌زاده مشايخ، ماهنامه گزارش كامپيوتر، شماره 194، آذر و دي 89، صفحه 62
جاشوا بلاك(Joshua Bloch) معمار ارشد جاوا در گوگل است.

گزيده:
من اساساً به مرور زمان نسبت به خودم سخت‌گيرتر شده‌ام و به همين دليل است كه اكنون برنامه‌هاي بهتري مي‌نويسم. شما نبايد عادت‌هاي بد خودتان را بپذيريد. جاشوا بلاك

نوشته دوست و استاد عزیزم علی آقای عبداللهی در وبلاگ ميزند باران به شيشه بهانه‌اي شد تا سپاس بي‌پايان خود و دوستانم را نثارشان كنم. اگر نبود کمک ایشان، بي‌شك انتشار كتاب با دشواري فراواني همراه مي‌شد.

«١۵٠٠ جلد از کتاب روش کاربردی تحلیل نیازمندی ‌های نرم افزار تالیف دوستان عزیزم اقایان یوسف مهرداد بی بالان، مظفر ایراف و پویا شهبازیان را خریده ام تا یک جلدش را ١۵٠٠ بار بخوانم.
کتاب در باره اولین فاز از تولید نرم افزار یعنی نیاز سنجی است. برای تولید هر نرم افزار اولین قدم این است که بدانیم نرم افزار چه کاری برایمان انجام دهد. یعنی نیاز سنجی.

مسلم است که نیازسنجی خوب پایه و اساس خوبتری است برای نرم افزار خوب و هر چه این نیاز سنجی بخوبی دیده شده باشد، نرم افزار خوبتر و کامل تر است و دردسرهای ناشی از نگهداری و پشتیبانی نرم افزار نیز کمتر است.

البته نیازها در حین توسعه و بهره برداری از نرم افزار ممکن است دستخوش تغییرات شوند که معمولا” در یک چرخه دائمی منجر به تغییر مستندات نیازسنجی، تحلیل، طراحی و پیاده سازی و … میشوند.

برای ما که وقت کمتری برای شرکت در کلاس داریم خواندن چنین کتابهایی که حاصل تحربیات عملی و اموزشی دوستان فعال در این زمینه هاست غنیمت است.

من ١۵٠٠ جلد از کتاب روش کاربردی تحلیل نیازمندی ‌های نرم افزار را خریده ام تا یک جلد آنرا ١۵٠٠ بار بخوانم و ١۴٩٩ جلد باقیمانده را به مدیران فن اوری اطلاعات اداراتی که مشتری نرم افزارهای یکپارچه مالی و اداری هوشا هستند هدیه بدهم و یا توصیه کنم و یا در اختیار مدیران و کارشناسان تیم های تحلیل،تولید و توسعه نرم افزار قرار دهم و یا در میان دانشجویان رشته های مرتبط با طراحی و تولید نرم افزار توزیع کنم .

امید دارم این کتاب را تهیه کنند و بخوانند. این کتاب ترجمه نیست بلکه حاصل تجربه است. تجربه کسانی که در تیم های خوبی کار کرده اند. و حاضر شده اند تجارب خود را در قالب کتاب در اختیار دیگران قرار دهند. با این امید که موجب توسعه علمی و عملی روش های تحلیل و توسعه نرم افزار شوند و با امید به اینکه استقبال جامعه فن آوری اطلاعات از چنین کتابهایی موجب رشد چنین کتابهایی در مقابل کتابهای صرفا” ترجمه شود.»

گزیده:
سه چیز انسانها را می سازند: کار سخت، صمیمیت و تعهد.