کلیسای جامع و بازار - قسمت پنجم(749 مجموع کلمات موجود در متن) (8538 بار مطالعه شده است)  برنامه
fetchmail
رشد
میکند
حال،
من طرح برنامه ای ابداعی و منظم را در
اختیار داشتم و به خوبی میدانستم که در
کارم موفق بودهام چرا که هر روز از آن
استفاده میکردم، و لیست بتائی که صحت
این ادعا را تائید میکرد.
بتــدریج
حــس میکردم کــه ابتـکارهای کوچکی که
ممــکن است برای افراد کمی سودمند باشد،
دیـگر مرا ارضاء نمیکند.
مــن
در نــوشتن بـرنامهای دســت داشتم که
برای هر هکری که از یک نسخه یونیکس و یک
کانکشن میل SLIP/PPP
استفاده
میکند، حقیقتا مفید بود.
با
قابلیت ارسال SMTP،
برنامه به شدت از سایر رقیبان خود پیشی
گرفته بود و به چنان برنامه قدرتمندی
تبدیل شده بود که نه تنها سایر رقیبان خود
را از راه بدر کرده بود، بلکه آنها را به
بوته فراموشی سپرده بود.
حدس
میزنم که حتی نتوانید چنین نتیجهای
را متصور شوید.
تنها
زمانی میتوانید، به این درک برسید کــه
چـنان قدرت تحلیلی در طراحی نرم افزار
داشته باشید که نتیجه کار برایتان محرز
و طبیعی جلوه کند.
تنها
روش بــرای حصــول چـنـین افکاری، با
داشتن ایدههای زیادی در ذهنــتان حاصل
میشود – و یـا بوسیله یک نوع تیز بینی
منهدسی وار، تا ایدههای خوب دیگر افراد
را در ماوراء نحوه نگرش آنها به چنگ آورید.
اندرو
تننبام ایده اصلی ساخت یک سیستم عامل
کوچــک محلی شبیه یونیکس را برای ماشـینهای
386
داشت
تا از آن به عنوان ابــزاری برای تدریس
استفاده کند.
لینــوس
توروالدز ایـده Minix
را
به حدی ارتقاء داد که تصورش برای اندرو
بعید بود و آن را به چیزی ارزشمند و شگفت
انگیز تبدیل کرد.
بـه
همین روش (هر
چند در مقیاس کوچکتری)،
مـن ایدهائی را از کارل هریس و هری هاچیسر
دریافت کردم و آنها را به سطح بالاتری
ارتقا دادم.
ما
مبتکرانی چنانکه مردم در تصورشان آن را
به نابغه تعبیر میکنــند، نبودیم.
از
ســوی دیگر، اکثر پیشرفتهای علوم مختلف
و رشتههای فنی مهنــدسی و نرمافزار
نیز بوسیله مبتکرانی نابغه صورت نگرفته
است؛ البته جدای برخی از اساطیر برنامه
نویس.
تنایج
حاصل مست کننده بود.
در
حقیقت، نوعی از موفقیت که هر هکری برای
آن و به امید آن زندگی میکند!
و
هـمـه اینها به این معنی بود که من
میتوانستم سطح استــانداردهایم را
حتــی فراتر از این نیز ببرم.
برای
انکه fetchmail
را
به آن خــوبی کــه در خــورش بــود تبدیل
کنم، میبایست عــلاوه بــر برآورده
کردن نیازهای شخصیام در نوشتــن بـرنامه،
جنبههای مورد نیاز دیگر افراد را هر
چنـد که خارج از حوزه نیازهای من باشد،
لحاظ میکردم.
و
البته همه این کارهـا را به گونهای انجام
دهم که برنامه همچنان ساده اما قدرتمند
باقی بماند.
اولین
و مهمترین ویژگی که من بعد از درک این نکته
به برنامهام اضافه کردم، قابلیت پیشتیبانی
از multidrop
در
برنامهام بود.
امکان
دریافت نامه از میل باکسهائی که تمامی
نامهها را برای یک گروه از کاربران
نگهداری میکنند، و سپس هر نامه را به
گیرنده مخصوص خود ارسال میکنند.
تصمیم
اضافه کردن این قابلیت به برنامه، کمی به
دلیل اصرار های پیاپی بعضی از کاربران،
و بیشتر به این خاطر بود که فکر میکردم
که اجبار حاصل در کار با آدرس های اینچنینی
میتواند خطاهای برنامه قبلی را کـاهـش
دهــد؛ و همـینطور نیز شد.
بررسی
RFC
822 زمــان
زیادی برد، نــه به این دلیل که هیچ بخشی
از آن سخت بوده باشد، بلکه به این خاطر که
حاوی تودهای از اطلاعات بهم مرتبط و
جزئی بود.
اما
نحوه آدرس دهی multidrop،
نتیجه تصمیم یک طرح عالی را به خوبی نشان
داد.
اینجا
بود که فهمیدم :
هر
ابزاری در جای خود، مفــید و سـودمـند
اسـت، امـا یـک ابزار واقعا سودمند آنچنان
در استفاده منعطف است که حتی تصوش را هم
نمیکنید.
کاربرد
غیر منتظره قابلیت multidrop
در
برنـامـه fetchmail،
در کـار بـا فهـرستهای پستی بــا
نگـهداشتن لیست، و نیـز امکان بسـط نامهای
مستعار، در سـمـت سـرویس گیــرنده یـک
کـانـکشن SLIP/PPP
بـود.
ایـن
امـر بـه ایـن معنی بود که شخصی که در پشـت
یه ماشین شخصی نشسته و از یک اکانت ISP
استفاده
میکند، قادر به مدیریت فهرست پستی خواهد
بود، بدون اینکه نیازی به رجوع به فایلهای
نام های مستعار ISP
داشته
باشد.
تغییر
مهم دیگری که تست کنندههای بتای نرمافزار
خواستار آن شده بودند، پیشیبانی از عملیات
8-بیتی
MIME
بود.
انجــام
این کار بسیـار سـاده بود، چــرا کــه
حـواسـم بـه کـدهـای 8-بیتی
بـود؛ نه به خاطر این که من احتمال درخواست
این ویژگی را از قبل پیش بینی میکردم،
بلکه بدلیل پیروی از اصلی دیگر:
وقتی
که نرم افزار دروازه ای، از هر نوعی
میخواهد باشد، مینویسید، تلاش بسیاری
کنید تــا جــریان داده شـما تا حد امکان
کوچک شود و *هیچگاه*
اطلاعات
را دور نریزید، مگر اینکه گیرنده شما را
مجبور به این کار کند.
اگر
از این اصل پیروی نمیکردم، آنــوقت
پشــتـیبانی از MIME
هشت
بیتی، سخت و مشکل ساز میشد.
در
آن صـورت، مجبور بودم تا تمامی RFC
1652 را
بخوانم تا چند بیت به ساختار تولید سرایند
اضافه کنم.
برخی
از کاربران اروپائی، مصرانه خواستار
گنجاندن گزینهای برای مــحدود ساختن
تعداد پیغامهائی کــه در هر جلسه بازیابی
میشود، شدنـد (که
در این صورت، آنها میتوانستند هزینههای
گــران شبکههای تلفنشان را کنترل کنند).
مــن
مدت زمان زیادی بر این موضوع پافشاری و
با درخواستشان مخالفت میکردم، و هنوز
هـم واقعــا از آن تغییـر دل خوشی ندارم.
اما
زمانی که شما برای کاربران جهان برنامه
مینویسید، باید به نظرات مشتریانتان
گوش کنید.
ایـن
مسئـله حتی در زمانی که آنها پولی به شما
نمیدهند، هم صادق است.
ترجمه:
نیما ابوطالبی
nima717a@yahoo.com
منبع:
http://www.catb.org/~esr/writings/cathedral-bazaar/
PDF Version
|