حال که موضوع حقوق کاربران به میان آمد، می‏خواهم لطيفه‏ای تعریف کنم با یادی از دوست خوبم، احسان (که دیرزمانی است که او را ندیده‏ام و واقعاً دلم برایش تنگ شده است)، چرا که این لطیفه را اولین بار برایم تعریف کرد.
می‏گویند یکی از هلی‏کوپترهای یکی از پایگاه‏های نظامی آمریکا در یکی از مأموریتهایش، مسیر بازگشت به پایگاه را گم کرد. خلبان ساختمانی را در آن نزدیکی دید، نزدیک ساختمان شد و کمک خلبان چیزی روی کاغذ نوشت و به کارکنانی که در ساختمان پشت کامپیوترهایشان مشغول کار بودند، نشان داد. کارکنان هم در جواب، نوشته‏ای روی کاغذ نوشتند و به خلبان و کمک خلبان نشان دادند.
خلبان نگاهی به نقشه‏ای که کنارش بود، انداخت و به سمت پایگاه پرواز کرد. بعد از چند ساعت، فرمانده پایگاه با آقای بیل گیتس تماس گرفت و از ایشان و کارمندان مایکروسافت بابت راهنمایی خلبان، تشکر کرد. آقای گیتس که متعجب شده بود، جویای جریان شد. فرمانده پادگان، خلبان را خواست تا برای آقای گیتس، ماجرا را شرح دهد. خلبان گفت که وقتی ما گم شده بودیم، کمک خلبان روی کاغذ نوشت که “ما کجا هستیم؟” و به کارمندان نشان داد. آنها هم در پاسخ نوشتند که “شما در هلی‏کوپتر هستید”. من و کمک خلبان به این نتیجه رسیدیم که اینجا، جایی نیست جز ساختمان شرکت مایکروسافت. از روی نقشه، آنجا را پیدا کردیم و به کمک آن به پایگاه برگشتیم.

نکته: طنز اشاره دارد به پیغامهای نرم‏افزارهای شرکت مایکروسافت که خنده‏دارترین پیغامها را برای راهنمایی کاربر اعلام می‏کنند.

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

ریش = زخم
گلستان سعدی، باب هشتم، حکایت بیست و نهم

چند وقت پيش در وبلاگهای برخی از دوستان از جمله مهندسی نرم‏افزار، به موضوعی اشاره شده بود با عنوان “حق با مشتری است یا نه؟”.
این موضوع از وجوه مختلف قابل بررسی است. در اینجا می‏خواهم به نتیجه تحقیق دکتر Karat(دکترای روانشاسی) در مرکز تحقیقات واتسون شرکت IBM در سال 1998 با عنوان حقوق کاربران کامپيوتر (Computer User’s Bill of Rights) اشاره کنم.
موارد زیر حقوقی است که ما برای کاربران قائل شدیم، پس راهی برای احترام به حقوق دیگران باید پیدا کنیم اگر می‏خواهیم حقوق خودمان رعایت شود.

1. The user is always right. If there is a problem with the use of the system, the system is the problem, not the user.
2. The user has the right to easily install software and hardware systems.
3. The user has the right to a system that performs exactly as promised.
4. The user has the right to easy-to-use instructions for understanding and utilizing a system to achieve desired goals.
5. The user has the right to be in control of the system and to be able to get the system to respond to a request for attention.
6. The user has the right to a system that provides clear, understandable, and accurate information regarding the task it is performing and the progress toward completion.
7. The user has the right to be clearly informed about all system requirements for successfully using software or hardware.
8. The user has the right to know the limits of the system’s capabilities.
9. The user has the right to communicate with the technology provider and receive a thoughtful and helpful response when raising concerns.
10. The user should be the master of software and hardware technology, not vice-versa. Products should be natural and intuitive to use.

گزیده:
خلعت سلطان اگر چه عزیز است، جامه خلقان خود به عزت‏تر. خوان بزرگان اگر چه لذیذ است، خرده انبان خود به لذت‏تر.
سرکه از دسترنج خویش و تره بهتر از نان دهخدا و بره
گلستان سعدی، باب هشتم، حکایت هشتاد و دوم

به همه دوستان عزيزم درود می‏فرستم و بابت اینکه نگرانشان کردم، از تک تکشان می‏کنم.
در چند هفته اخیر، به دلیل انجام امور شغلی، هم فرصت کافی برای نوشتن نداشتم و هم تمرکز لازم. همه این تجربه را داشته‏ایم که وقتی چرخ‏دنده‏های زندگی از نظم خارج شوند، برگرداندن آنها به نظم پيشين، اصلاً کار ساده‏ای نیست. این به آن معنا نیست که خیلی منظم هستم. بلکه بدین معنی است که آن بی‏نظمی پيشین (و قابل تحمل) نیز از بین رفته بود.
در این مدت دلم برای وبلاگ و دوستانم خیلی تنگ شده بود. شاید این هم نوع جدیدی از دلتنگی است: سایبردلتنگی.

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

از من به تو نصیحت؛‌ لذت بردن از زندگی را جزو TODOهایت قرار نده.

//TODO: Please implement it right now
public void EnjoyYourLife()
{
}

مرجع: Sharpedia

گزیده:

There are three things I always forget: Names, Faces, and the third I can’t remember. Italo Svevo

چندماهی است که در پروژه‏هایی همکاری می‏کنم که نگاه “معماری سرويس گرا”- Service Oriented Architecture- در آن غالب است. در این پروژه‏ها، این نگاه از سوی کارفرما به عنوان یک “الزام” مورد تأکید قرار گرفته است. هر چند باید یادمان باشد که این رویکرد، تنها رویکردی است به معماری و نه همه ارکان توسعه نرم‏افزار. صرف نظر از مثبت بودن نگاهم به این رویکرد، موضوعی که همواره در این گونه موارد مرا نگران می‏کند، آسیب‏شناسی آنهاست؛ چرا که تجربه‏ی عملی از آن در کشور وجود ندارد و از طرف دیگر به دلیل نیاز مطرح نمی‏شوند بلکه به دلیل شانتاژهای مقالات و محتوای اینترنتی این کار صورت می‏گیرد. هر چند اعتقادم این است که نداشتن روالهای مناسب برای جذب رویکردها، روشها و تکنولوژِی‏‏ها، یکی از معضلات مهم جامعه IT ماست. صرف نظر از مثبت بودن نظرم درباره این رویکرد، وقت زیادی را برای پیدا کردن پاسخ سؤالهایم (سؤالهایی که منشأ از نگرانی‏ام دارند) صرف می‏کنم. مقاله زیر از گریدی بوچ، یکی از پاسخهایی است که پیدا کرده‏ام. امیدوارم برای شما هم مفید باشد.
همچنین توصیه می‏کنم که مجله Objective View را هم مطالعه نمایید. مطالعه آن برای من همیشه مفید بوده است.

I not so long ago returned from some work with the SEI in Pittsburgh and then in Washington, DC where I conducted a number of customer visits primarily focusing on service oriented architecture.
Comments about hunting with Dick go over really, really well with the DC crowd.
My take on the whole SOA scene is a bit edgier than most that I’ve seen. Too much of the press about SOA makes it look like it’s the best thing since punched cards. SOA will apparently not only transform your organization and make you more agile and innovative, but your teenagers will start talking to you and you’ll become a better lover. Or a better shot if your name happens to be Dick. Furthermore, if you follow many of these pitches, it appears that you can do so with hardly any pain: just scrape your existing assets, plant services here, there, and younder, wire them together and suddenly you’ll be virtualized, automatized, and servicized.
What rubbish.
SOA is, first and foremost, about the A part of the acronym (architecture). Organizations who already have a solid approach to architecture will likely do reasonably well with SOA; organizations who already have a broken architecture and/or a broken architectural governance practice will likely fail with SOA and then blame SOA on all their problems.
If you follow the history of web-centric systems, services (with a small s) are a very logical progression of web mechanisms. From a technical perspective, SOA is nothing revolutionary, it’s evolutionary. BTW, in this context, the concept of an enterprise service bus can be easily explained as a very elegant and simple pattern for location independence/message translation.
There are places where SOA is suitable, and places where it is not. SOA, from my experience, is one specific architectural style appropriate for systems of systems wherein some but not necessarily all of those systems are already web-centric. This is an important point: SOA is a useful but insufficient mechanism for architectural decomposition. Some would suggest that SOA is all you need. This is seriously wrong.
To that end, services (with a small s) are best suited to relatively large grained/low frequency interactions rather than small grained/high frequency interactions. For that latter situation, other, more traditional, mechanisms of RPC and/or message passing are better suited.
A serious gap in the current state of the art of services is that we simply don’t know how to specify quality of service very well at all. It’s one thing to wire together services a la National Instrument’s LabView, it’s another if there are quality/performance/reliability/security/dependability issues for each of those channels and each of those ports.
There are also services with a big S: there is a conceptual kind of service that is not manifest as a pure WSDL service but rather something else. Think of a service as a port on a system, with that port having a well-defined interface consisting of a vocabulary of classes, a protocol, and a particular set of messages and resulting behavior. It is a good thing that you can conceptualize a system as a web of services, some of which are Services and some of which are, well, services.
Going back to the A part of SOA, the issue then is one of abstraction, separation of concerns, and all the usual fundamentals of architecture. I’ve seen some folks suggest creating an SOA from the bottom up: look at a silo, identify the potential services, and publish them, then weave a system together from them. This is in essence technology first. In my experience, this is a recipe for disaster and/or serious over-engineering. You’ve got to start with the scenarios/business needs, play those out against the existing/new systems, zero in on the points of tangency, and there plan a flag for harvesting a meaningful service. These styles, and their resulting costs/benefits, are rarely discussed.
In a couple of weeks, I’m off to a very different venue, where I’ll be giving a talk at the Game Developer’s Conference in San Jose. Developing software for games is big business, and this community is starting to discover that the fundamentals are important: you can’t build an enduring a business just by hiring bright people, throwing them in a room together, and hoping that they’ll do great things.

Refs: ObjectiveView A Magazine for the Professional Software Developer, Issue 10

گزیده:

I don’t pretend we have all the answers. But the questions are certainly worth thinking about. Arthor Clark

با خواندن مطلب زیر نه تنها مطالب جدیدی یادگرفتم، بلکه به شدت خندیدم. خلاصه‏ای از آن را در اینجا آورده و آدرس آن را نیز در ادامه آورده‏ام.

In the interests of creating employment opportunities in the Java programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain, that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will even guarantee yourself a lifetime of employment, since no one but you has a hope in hell of maintaining the code. Then again, if you followed all these rules religiously, even you wouldn’t be able to maintain the code.

* Documentation :
Any fool can tell the truth, but it requires a man of some sense to know how to lie well.

* Program Design :
The cardinal rule of writing unmaintainable code is to specify each fact in as many places as possible and in as many ways as possible.

*Testing:
I don’t need to test my programs. I have an error-correcting modem.

*Dealing With Others:
Hell is other people.

*Roll Your Own:
You’ve always wanted to write system level code. Now is your chance. Ignore the standard libraries and write your own. It will look great on your resumé.

*Miscellaneous Techniques:
If you give someone a program, you will frustrate them for a day; if you teach them how to program, you will frustrate them for a lifetime.

refs: http://www.web-hits.org/txt/codingunmaintainable.html

گزیده:
لقمان را گفتند: ادب از که آموختی؟ گفت از بی‏ادبان. هر چه از ایشان در نظرم ناپسند آمد، از فعل آن پرهیز کردم.
نگویند از سر بازیچه حرفی — کزان پندی نگیرد صاحب هوش
وگر صد باب حکمت پیش نادان — بخوانند آیدش بازیچه در گوش
گلستان سعدی، باب دوم، حکایت بیستم.

I’m passionate about creating great software, I believe creating great software can help create great businesses: either its the software products you sell or the software that allows the business to be great.
I believe software systems done well can help us grow and learn as businesses and as individuals; done badly they can hold us back. Software alone is not enough: you have to learn and change, this is how we create knowledge.
The immediate problem I see is: how do we make our software development better? How do we improve the team? Yet this is only the start of the problem, the real problem is: how do I make my business better? How do I improve my products and services?
ref: http://www.allankelly.net/

گزیده:

Alfredo: [after informed about the arrival of the new non-combustible film] Progress always comes late. –Cinema Paradiso