از من به تو نصیحت؛‌ لذت بردن از زندگی را جزو 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

 

معلم يک کودکستان به بچه هاي کلاس گفت که ميخواهد با آنها بازي کند. او به آنها گفت که فردا هر کدام يک کيسه پلاستيکي بردارند و درون آن به تعداد آدمهايي که از آنها بدشان ميآيد، سيب زميني بريزند و با خود به کودکستان بياورند.
فردا بچه ها با کيسه هاي پلاستيکي به کودکستان آمدند. در کيسه بعضي ها ۲، بعضي ها ۳، و بعضي ها ۵ سيب زميني بود.
معلم به بچه ها گفت: تا يک هفته هر کجا که مي روند کيسه پلاستيکي را با خود ببرند. روزها به همين ترتيب گذشت و کم کم بچه ها شروع کردند به شکايت از بوي سيب زميني هاي گنديده. به علاوه، آن هايي که سيب زميني بيشتري داشتند از حمل آن بار سنگين خسته شده بودند. پس از گذشت يک هفته بازي بالاخره تمام شد و بچه ها راحت شدند.
معلم از بچه ها پرسيد: از اينکه يک هفته سيب زميني ها را با خود حمل مي کرديد چه احساسي داشتيد؟ بچه ها از اينکه مجبور بودند، سيب زميني هاي بد بو و سنگين را همه جا با خود حمل کنند شکايت داشتند.
آنگاه معلم منظور اصلي خود را از اين بازي، اين چنين توضيح داد:
اين درست شبيه وضعيتي است که شما کينه آدم هايي که دوستشان نداريد را در دل خود نگه مي داريد و همه جا با خود مي بريد. بوي بد کينه و نفرت، قلب شما را فاسد مي کند و شما آن را به همه جا همراه خود حمل مي کنيد. حالا که شما بوي بد سيب زميني ها را فقط براي يک هفته نتوانستيد تحمل کنيد
…
پس چطور مي خواهيد بوي بد نفرت را براي تمام عمر در دل خود تحمل کنيد؟
مرجع: http://zahra-hb.com

گزیده:

ما می‏خواهیم اینها (نرم افزار) ابزار ما باشند و نه ارباب ما.      یک مدیر ایرانی

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

گزیده:

 اشتباه را تصحيح نكردن، خود اشتباه ديگر است.