امروز نامه‏ای از دوست خوب و همکلاسی قدیمی‏ام، فرهاد داشتم راجع به جایزه سالانه “افشین جعفری مژدهی” برای بهترین مقاله دانشجویی در موضوع اقتصاد. آدرس ارسال شده را دنبال کردم و ….
روحش شاد. همکلاسی با معرفت، بمب خنده، باهوش و فعال در امور درسی و دانشجویی. با بیماری سختی دست به گریبان بود. آخرین باری که زنده بود، قرار بود در گردهمایی همکلاسی‏ها شرکت کند، که در آخرین لحظات نتوانست. چقدر حسرت خوردیم که ای کاش برای آخرین بار می‏آمد و ….

از بانیان این کار بزرگ، صمیمانه سپاسگذارم. حق یاورشان.

This webpage is dedicated to pay tribute to the memory of our dear friend, classmate and colleague, Afshin Jafari Mojdehi, who passed away on September, 10th 2003 after three years of courageous battle with Leukemia. He was 29 years old.

Afshin was a researcher and faculty member of IRPD (Institute for Research in Planning and Development) the pioneer center for research and graduate studies of economics in Iran. In IRPD he impressed senior faculty and graduate students with his passion and hard work. The students that attended Afshin’s classes enjoyed having an enthusiastic teacher willing to explore and discuss new horizons in economics theory and applications. In his short time as an economic researcher he participated in several research projects, which resulted in publishing a number of excellent reports and papers, his contribution to the quality of these articles was enormous. He was an extraordinary teacher and devoted researcher.

Afshin came from a small green city in north of Iran. He graduated from Sharif University in Tehran in class of 1997 (1376). He continued his graduate studies in IRPD, where he was invited to stay after graduation. He was a lovely young man, who in any occasion tried his best to make everybody around him happy, life was radiating from him. Decided not to share anything his illness with others, he didn’t mention it to anybody until his last weeks. So it became a shock for many to understand it later.

Now here we are, his friends and colleagues in Iran and abroad, making a pledge to prolong his devotion to the development of economic studies in Iran, in naming an annually award for the best graduate student paper in the field of economics. We know if he were here among us, he would be the most industrious one to pursue this contest, something he would have longed to do. And he is doing it right now, because he inspired many of us in many ways to like economics. To see the details about the prize visit Afshin Jafaris’s Prize Page.

گزیده:
ببار ای ابر بهار
ببار ای باران ببار
با دلم گریه کن خون ببار
دلم خون شد خون ببار
بر کوه و دشت و هامون ببار

به همگی دوستان عزیزم، سلام.

به قول مرحوم حاج قربان سلیمانی، استاد دو تار “گاهی دوتارم با من قهر می‏کند”. گاهی هر چه فکر می‏کنم، حرفی برای گفتم ندارم. انگار وبلاگم با من قهر می‏کند.

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

اگر نظری دارید بفرمایید تا در نهایی‏کردن قالب وبلاگ در نظر گرفته شود.

گزیده:

دندون اسب پیش‏کش رو، در هنگام تحویل می‏شمارند.

خانم مهندس کراری در توضیحی برایم نوشته بودند:
“….ولی قکر میکنم اگر شرکتها و سازمانها به نیروی انسانی به اندازه کافی بها می دادند اوضاع سودآوری شون حتما بهتر از اینی که هست می شد و حداقل می دیدیم که آرزوی هر نیروی 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 دقیقه

h