خانم مهندس کراری در توضیحی برایم نوشته بودند:
"....ولی قکر میکنم اگر شرکتها و سازمانها به نیروی انسانی به اندازه کافی بها می دادند اوضاع سودآوری شون حتما بهتر از اینی که هست می شد و حداقل می دیدیم که آرزوی هر نیروی IT داشتن یک شرکت مستقل نبود! "

ضمن تشکر از ایشان، گفتم شاید بد نباشد که حکایت جالب زیر را در اینجا بیاورم. اعتقاد شخصی من این است که ما مثل دانه‏های زنجیر به هم متصل هستیم (به عبارت فنی یک سیستم هستیم) که نمی‏شود تنها بخشی از آن را بدون در نظر گرفتن سایر اجزایش مورد بررسی و تحلیل قرار داد.  

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

گزیده:

There is always something for which to be thankful. —Charles Dickens

The Tyranny of Tools

I have seen teams attempt to enforce a style through the use of tools. Some tools are benign and helpful. Many IDEs, for example, allow you to specify things like indent level, brace placement, etc. With a single keystroke you can ensure that a batch of code conforms to the team style. I use tools like this, an depend upon them. I make sure that all the team members set their IDEs to use the conventions.

Other tools can be more intrusive. Some tools can act like compilers, generating errors if the style is not adhered to. Such tools might be useful for an occasional scan of the code; but I think you have to be very careful if you put them into the normal build cycle.

Automatic enforcement is power; and power corrupts. We do not want a well-meaning bureaucrat deciding, one day, to enforce the style that every function argument must have a javadoc comment. This leads to comments of the form: //required comment.

This is not to say that tools like findbugs and checkstyle should be avoided. Indeed, I find them very useful. However, I think they should be run occasionally and manually, not as part of every build. The issues that these tools discover should be dealt with on a case-by-case basis.

Many tools like this allow you to insert special meta-comments that override the warnings. If these tools are placed in the build process; then the code will become cluttered with these meta-comments.

I have a pathological distaste for meta-comments.

Conclusion

Coding style is a matter of team pride and team identity. Teams should be free to adopt their own styles, and to change those styles as the spirit moves them. Each member of the team should follow the team style, and work to ensure that the body of code is a consistent statement of that style. If this sounds too artsy-fartsy, keep in mind that pride of workmanship is a powerful motivator. We want teams to be proud of their creations.

گزیده:

 Comments are free but facts are sacred. —Charles Prestwich Scott

Style not Substance

A good coding standard should be about style and form, not about substance. It should not attempt to legislate good design. It should not, for example, proscribe goto or public variables. Those rules are part of the body of knowledge that all software developers should have, and are not a matter of style.

Coding standards should be about the things that don’t matter. They should be about brace placement, naming conventions, the use of blank lines, indentation levels, etc. A coding standard should describe the way code looks, not the substance the code is made from.

It is important to keep style and substance separate because they matter for different reasons. Issues of style matter only for consistency. It does not matter whether your indent depth is 2 or 4, so long as everyone uses the same depth. It does matter if you use public variables inappropriately.

Oral/Code Tradition

Documents that describe coding standards tend to be useless. They often become a bloated battleground for many different competing ideas. My advice is to avoid writing them.

The real document that describes your coding standard is your code. If you want to know how to name a variable, look at how they are named in the code. If you want to know what the standard indent depth is, look in the code. The code is the living document that describes the coding standard.

Oral tradition plays a role as well; especially when communicating issues of substance vs. style. Teams should make use of code reviews and pair programming to communicate with each other about issues of style and substance. New members of the team should have frequent exposure to the more seasoned members, so that the issues of style and substance are inculcated with moral authority. Nothing is quite as persuasive to a young programmer than pairing with the lead programmer and hearing him say: “We don’t do things that way; we do things this way.”

گزیده:

 Real seriousness in regard to writing is one of two absolute necessities. The other, unfortunately, is talent.  Ernest Hemingway

  یکی از مهمترین مراحل در توسعه نرم‏افزار، برنامه‏نوسی و کدنویسی آن است و یکی از مهمترین مشکلات در این مرحله، کم‏کیفیت و ناهمگون بودن کدی است که توسط برنامه‏نویسان نوشته می‏شود.  برای حال یا کاهش اثر این معضل، یکی از روشهایی که معمولاً به کار می‏بریم، تدوین استانداردهای برنامه‏نویسی است که برنامه‏نویسان ملزم به پیروی از آن هستند. Robert Martin در نوشته‏ای به بررسی این موضوع پراهمیت پرداخته است.  

Coding Standard
Coding Standards are a good idea. Every team should adopt a coding style and standard, and stick to it. The code produced by that team should have a consistent look and feel that is devoid of individual preferences and fetishes.

Of course this means that the members of the team will have to be mature enough to realize that it doesn’t really matter where they put their braces, or how they adorn their member variables. What matters is that they all use the same conventions.

Consistency

My goal for a good coding standard is to eliminate individual styles in favor of a team style. The code produced by a team should look like the team produced it. I don’t want any code recognizable as Bob’s or Bill’s.

This is not some egalitarian fantasy to hide individuality for the sake of the collective. Rather, it is a raw necessity. We’ve all seen products that look like they were designed by a committee. We’ve all used software products where the look and feel changed depending on which part of the application you were using. The result feels messy, clumsy, inefficient.

Individuals, used to their own particular style, will reformat other people’s code when forced to work on it, further shuffling the patchwork of styles. Over time, as each team member touches different parts of the code, and team members come and go from the team, the code begins to look like a jumbled Rubick’s cube of different styles.

Code is a product, in and of itself. The team producing it needs to take pride in the elegance of it’s structure, and the expressiveness of it’s presentation. This kind of pride is infeasible when the code is crisscrossed with a patchwork of individual styles. Without this pride, there is no drive to keep the overall product clean. Without that cleanliness, messes build up at the boundaries. And, as we all know, messes slow us down, and they spread.

گزيده:

Write your code to be read. By humans. Easily. The compiler will be able to cope.   Pete Goodliffe
 

Concept-orientation is a new emerging programming, data modelling and system design paradigm. The main purpose of this site is to serve as a growing resource sharing and organizing the work and thoughts on this new direction in computer science for those interested in learning about it.
Main principles of the concept-oriented programming:
1. Separation of business methods (BMs) and representation and access (RA) methods.
2. Objects live in spaces and any BM call has to intersect a sequence of borders in order to access the object.
3. The spaces where objects live have a hierarchical structure.
4. Transparency of access.
Reference: The Concept-Oriented Portal

گزیده:
اگر مي خواهي براي حال و آينده مفيد باشي از گذشته درس بگير)ناپلئون(
مرجع:کمتر از 10 دقیقه

For the individuals considering a change in job, the reasons can be as many and varied as the personalities involved. For the organization with pathologically high turnover,a few reasons account for most departures:

• a just-passing-through mentality: Co-workers engender no feelings of long-term involvement in the job.
• a feeling of disposability: Management can only think of its workers as interchangeable parts (since turnover is so high, nobody is indispensable).
• a sense that loyalty would be ludicrous: Who could be loyal to an organization that views its people as parts?

آیا شما دلایل دیگری را هم سراغ دارید؟
مرجع: کتاب Productive Projects and Teams 2nd ed نوشته Tom DeMarco & Timothy Lister

گزیده:

The things two people do to each other they remember. If they stay together, it's not because they forget; it's because they forgive.  - Demi Moore in Indecent Proposal

Have you ever heard of SEMA? It's a fairly esoteric system for measuring how good a software team is. No, wait! Don't follow that link! It will take you about six years just to understand that stuff. So I've come up with my own, highly irresponsible, sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. With all the time you save, you can go to medical school.
The neat thing about The Joel Test is that it's easy to get a quick yes or no to each question. Give your team 1 point for each "yes" answer. The bummer about The Joel Test is that you really shouldn't use it to make sure that your nuclear power plant software is safe.

The Joel Test
   1. Do you use source control?
   2. Can you make a build in one step?
   3. Do you make daily builds?
   4. Do you have a bug database?
   5. Do you fix bugs before writing new code?
   6. Do you have an up-to-date schedule?
   7. Do you have a spec?
   8. Do programmers have quiet working conditions?
   9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

اکنون به تیم خود امتیاز بدهید. تیم شما چند امتیاز آورده است؟  برایم کامنت بگذارید.
مرجع: http://www.joelonsoftware.com

گزيده:

The only wrong thing would be to deny what your heart truly feels - THE MASK OF ZORRO

مطلب زیر را از وبلاگ مریم انتخاب کردم. برای خودم خیلی جالب بود.
پروفسور Walter H. G. Lewin استاد فیزیک دانشگاه MIT که به خاطر پادکست ها و ویدئو کست های کلاس هاش مورد توجه خیلی از علاقه مندان به فیزیک قرار گرفته.

این استاد فیزیک با انتشارپادکست های کلاسش در سایت درس های باز دانشگاه MIT و هم چنین در سایت iTune عده زیادی از علاقه مندان به رشته فیزیک رو به وجد اورد.جالبه در لیست تعداد دانلود های پادکست های این استاد از سایت iTunes در رتبه اول (نسبت به پادکست های اساتید دانشگاه های مختلف)قرار داره.هم چنین از هنگامی که دانشگاه ام ای تی پادکست های ایشون رو برای دوره های دبیرستان های آمریکا گسترش داد مورد استقبال خیل عظیمی از معلمین و دانش آموزان قرار گرفت.

شاید این سوال پیش بیاد که فرق ویدئو کست های پروفسور لوین(یا بهتر بگیم کلاس های درس ایشون) با بقیه اساتیدی که مطالبشونو از این طریق منتشر می کنن چیه.ایشون در واقع یه استاد منحصر به فرد برای بیان قوانین و اصول فیزیک هست. مثلا برای بیان “قانون پاندول ها” و اینکه دوره تناوب یک پاندول به جرم بسته شده بهش بستگی نداره یک آزمایش عجیب و جالب در کلاس خودش انجام داد.اون خودش رو از طنابی وسط کلاس آویزون کرد و خودش رو شروع به تاب دادن کرد.بعد با مقایسه دوره تناوب این حالت با حالتی که فقط یک گوی فلزی به طناب آویزون بود قانون پاندول ها رو به خوبی نشون داد.(نتیجه:دوره تناوب یک پاندول مستقل از جرم سیم،توپ فلزی وصل شده به آن و یک عدد استاده!)

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

“زندگی شما هیچ وقت تکراری نمیشه.شما به خاطر علم که دارید همیشه می تونید از ابعاد مختلف به پدیده ها نگاه کنید و از زیبایی منحصر به فرد اونها لذت ببرید”.این رو وقتی پروفسور لوین در یکی از کلاس های خودش که به توضیح قوانین اپتیکی و تشکیل رنگین کمان می پرداخت، خطاب به دانشجو هاش گفت.
یک معلم فیزیک عراقی در پی ایمیلی به این استاد عنوان میکنه “شما نقش پدر من در علم فیزیک رو داشتید.علی رغم حمله آمریکا به کشور عزیزم عراق و اشغال اون،تو باعث شدی من آمریکا رو دوست داشته باشم.چون تو در آنجا هستی”.
جالبه که بدونید این فیزیکدان برای هر جلسه حدود 25 ساعت وقت جهت آماده کردن موضوع درس،انجام حرکات مختلف با دقت تمام برای درست نشان دادن یک اصل فیزیکی و …. صرف می کنه.

منابع و لینک های مرتبط:
1- نیویورک تایمز
2- سایت درس های باز دانشگاه ام ای تی
3- اپل با iTunes U دانشگاه ها را به خانه شما می اورد.

گزیده:
انسانها دو دسته‏اند :آنهایی که بیدارند در تاریکی و آنهایی که خوابند در روشنایی.

مرجع: وبلاگ قند و نمک

پروفسور شلینگ برنده‌ی نوبل اقتصاد سال ۲۰۰۵ به شریف می‌آید. سوم دی ماه زمان حضور این دانشمند در دانشگاه شریف اعلام شده است.او در این روز در دانشگاه صنعتی شریف برای اساتید و دانش‌جویان سخنرانی خواهد کرد.
به دعوت دانشگاه صنعتي شريف، پروفسور توماس شلينگ که نوبل اقتصاد را به خاطر "بسط و توسعه‌ی درک تقابل‌ها و همکاری‌ها از طريق تحليل‌های نظريه‌ی بازی‌ها" دريافت نموده است، ۲۲ دسامبر برابر با اول دی ماه سال جاری به ايران مي آيد.
شلینگ کیست؟
پروفسور توماس شلينگ استاد دانشکده‌ی علوم سياسی دانشگاه‌های مريلند، جان اف کندی و هاروارد است. وی در سال ۱۹۹۱ به عنوان رييس مجمع اقتصاد آمريکا انتخاب شد و در حال حاضر نيز عضو برجسته‌ی اين مجمع است. ايشان همچنين موفق به دريافت جايزه‌ی عالی فرانک سيدمن در رشته‌ی اقتصاد سياسی و نيز جايزه‌ی فرهنگستان ملی علوم آمريکا شده است. از ديگر سوابق کاری ايشان مي توان به اشتغال در اداره‌‌ی کل فعاليت های اقتصادی اروپا، دانشگاه Yale ، موسسه‌ی Rand و مرکز امور بين الملل دانشگاه هاروارد اشاره داشت. هم اکنون پروفسور شلينگ به عنوان عضو برجسته‌ی انجمن ها‌ی ملی و بين المللی از جمله فرهنگستان ملی علوم آمريکا فعاليت می نمايد.
پروفسور شلينگ کتاب‌های متعددی در زمينه‌ی سياست‌های محيط زيست و انرژی، تغييرات اقليمی، کمک‌های خارجی، تجارت بين المللي، نظريه تقابل و چانه‌زنی، تبعيض و يکپارچگی نژادی، سياست‌های سلامت و بهداشت و موضوع اخلاق در سياست‌های بخش عمومی به رشته‌ی تحرير درآورده است. سخنرانی ايشان در دانشگاه شريف تحت عنوان "مديريت مشکلات گلخانه‌ای جهان" (Managing the World's Greenhouse Problem) در تاريخ دوشنبه ۲۴ دسامبر ۲۰۰۷ برابر با سوم دی ماه ۸۶ از ساعت ۳ تا ۵ بعد از ظهر در سالن جابربن حيان برگزار خواهد شد.
زندگینامه پروفسور شلینگ در سایت نوبل
منبع: سایت دانشگاه شريف

گزیده:
پهلوان روي تشك پهلوان نمي‏شود، بلكه روي تشك ديگران از پهلواني او با خبر مي‏شوند.

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

گزیده:
از دست و زبان که برآيد .........