There once was a man who went to a computer trade show. Each day as he entered the man told the guard at the door: “I am a great thief, renowned for my feats of shoplifting. Be forewarned, for this trade show shall not escape unplundered.”

This speech disturbed the guard greatly, because there were millions of
dollars of computer equipment inside, so he watched the man carefully. But the man merely wandered from booth to booth, asking questions and
humming quietly to himself.

When the man left, the guard took him aside and searched his clothes, but nothing was to be found. On the next day of the trade show, the man
returned and chided the guard saying: “I escaped with a vast booty
yesterday, but today will be even better.” So the guard watched him ever
more closely, but to no avail.

On the final day of the trade show, the guard could restrain his curiosity no longer. “Sir Thief”, he said, “I am so perplexed, I cannot live in peace.

Please enlighten me. What is it that you are stealing?”
The man smiled. “I am stealing patterns“, he said.

Reference: Pattern-Oriented Software Architecture, Patterns for Concurrent and Networked Objects, Volume 2

گزیده:

Don’t be too timid and squeamish about your actions. All life is an experiment. The more experiments you make the better.
Ralph Waldo Emerson US essayist & poet (1803 – 1882)

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

گزيده:
هر وقت كه به آينده نگاه مي‌كني، مي‌بيني كه مي‌تواني آن را عوض كني.
نيكولاس كيج در فيلم آينده

احتمالاْ این نوشته، طولاني‌ترين نوشته وبلاگ خواهد شد.
فهرست زير شامل نود و هفت پند و ارز است براي معماران نرم‌افزار كه توسط تعدادي از خود آنان نوشته شده است.
اين متن را خانم ملكوتي‌خواه برايم ارسال نموده‌اند كه صميمانه از ايشان تشكر كرده و برايشان آرزوي توفيق دارم.

The following are axioms for software architects by software architects.
The following are the 97 axioms selected for the book, 97 Things Every Software Architect Should Know, which will be published by O’Reilly Media in early 2009.

1. Don’t put your resume ahead of the requirements by Nitin Borwankar

2. Simplify essential complexity; diminish accidental complexity by Neal Ford

3. Chances are your biggest problem isn’t technical by Mark Ramm

4. Communication is King by Mark Richards

5. Architecting is about balancing by Randy Stafford

6. Always ask for the value to be provided by a requested capability by Einar Landre

7. Stand Up! by Udi Dahan

8. Talk about the arch, but se the scaffolding beneath it by Micheal Nygard

9. You’re negotiating more often than you think by Michael Nygard

10. Quantify by Keith Braithwaite

11. One line of working code is worth 500 of specification by Allison Randal

12. There is no one-size-fits-all solution by Randy Stafford

13. It’s never too early to think about performance and resiliency testing by Rebecca Parsons

14. Application architecture determines application performance by Randy Stafford

15. Commit-and-run is a serious crime. Respect your Colleagues by Niclas Nilsson

16. There Can be More than One by Keith Braithwaite

17. Business Drives by Dave Muirhead

18. Simplicity before generality, use before reuse by Kevlin Henney

19. Architects must be hands on by John Davies

20. Continuously Integrate by Dave Bartlett

21. Sometimes it’s better to let the train pass you by by Norman Carnovale

22. Architectural Tradeoffs by Mark Richards

23. Database as a Fortressby Dan Chak

24. Use uncertainty as a driver by Kevlin Henney

25. Scope is the enemy of success by Dave Quick

26. Reuse is about people and education, not just architecture by Jeremy Meyer

27. There is no ‘I’ in architecture by Dave Quick

28. Get the 1000ft view by Erik Doernenburg

29. Try before choosing by Erik Doernenburg

30. Understand The Business Domain by Mark Richards

31. Programming is an act of design by Einar Landre

32. Time changes everything by Philip Nelson

33. Take the hill! by Philip Nelson

34. Value stewardship over showmanship by Barry Hawkins

35. If you’re unwilling to be hands-on, maybe you should keep your hands off by Barry Hawkins

36. The title of software architect has only lower-case ‘a’s; deal with it by Barry Hawkins

37. Software architecture has ethical consequences by Michael Nygard

38. Everything will ultimately fail by Michael Nygard

39. Context is King by Edward Garson

40. It’s all about performance by Craig L Russell

41. Engineer in the white spaces by Michael Nygard

42. Talk the Talk by Mark Richards

43. Heterogeneity Wins by Edward Garson

44. Dwarves, Elves, Wizards, and Kings by Evan Cofsky

45. Learn from Architects of Buildings by Keith Braithwaite

46. Fight repetition by Niclas Nilsson

47. Welcome to the real world by Gregor Hohpe

48. Don’t Control, but Observe by Gregor Hohpe

49. Architect as Janitor by Dave Bartlett

50. Architects focus is on the boundaries and interfaces by Einar Landre

51. Challenge assumptions – especially your own by Timothy High

52. Record your rationale by Timothy High

53. Empower developers by Timothy High

54. It is all about the data by Paul W. Homer

55. Control the data, not just the code by Chad LaVigne

56. Architecture Metaphors Can Only Be Stretched As Far As A, Um, Stretchy Thing by David Ing

57. If the application can’t be supported, the project is a failure by Mncedisi Kasper

58. Lead by Influence by Travis Illig

59. Prefer principles, axioms and analogies to opinion and taste by Michael Harmer

60. From Pencil Neck Geek to Mr. Olympia by Clint Shank

61. Share your knowledge and experiencesby Paul W. Homer

62. Make sure the simple stuff is simple by Chad LaVigne

63. If you design it, you should be able to code it by Mike Brown

64. The ROI variable by George Malamidis

65. Your system is legacy, design for it by Dave Anderson

66. If there is only one solution, get a second opinion by Timothy High

67. Requirements are not the measure of success but the beginnings of a conversation by Christopher Dempsey

68. Capacity to implement is as important as knowing how to implement by Kamal Wickramanayake

69. Shortcuts now are paid back with interest later by Scot Mcphee

70. “Perfect” is the Enemy of “Good Enough” by Greg Nyberg

71. Avoid “Good Ideas” by Greg Nyberg

72. Great content creates great systems by Zubin Wadia

73. The Business Vs. The Angry Architectby Chad LaVigne

74. Stretch key dimensions to see what breaks by Stephen Jones

75. Before anything, an architect is a developer by Mike Brown

76. A rose by any other name will end up as a cabbage by Sam Gardiner

77. Stable problems get high quality solutions by Sam Gardiner

78. Diligence and the Mundane by Brian Hart

79. Take responsibility for your decisions by Yi Zhou

80. Dont Be a Problem Solver by Eben Hewitt

81. Software Should Be Invisible by Eben Hewitt

82. Your Customer is Not Your Customer by Eben Hewitt

83. It will never look like that by Peter Gillard-Moss

84. Choose Frameworks that play well with others by Eric Hawthorne

85. Making a strong business case by Yi Zhou

86. The insidious pattern bug by Chad LaVigne

87. Learn a new language by Burk Hufnagel

88. Dont Be Clever by Eben Hewitt

89. Build Systems to be Zuhanden by Keith Braithwaite

90. Employ developers that are recognition motivated by Chad LaVigne

91. Software doesnt really exist by Chad LaVigne

92. Pay down your technical debt by Burk Hufnagel

93. You can’t future-proof solutions by Richard Monson-Haefel

94. Interaction Design is Critical by Richard Monson-Haefel

95. The Importance of Consommé by Eben Hewit

96. For the end-user, the interface is the system by Vinayak Hegde

97. Great software is not built, it is grown by Bill de hÓra

گزيده:

Modeling Principle: Design a model so that the most frequent modification of the model causes changes to the least number of types. Martin Fowler, Analysis Pattern

My husband and I are both in an Internet business, but he’s the one who truly lives, eats and breathes computers. I finally realized how bad it had gotten when I was scratching his back one day. “No, not there,” he directed. “Scroll down.”

Ref: readersdigest.com

گزيده:
خنده بر هر درد بي‌درمان دواست.

A list of top N risks, especially during risk survey, is helpful in getting a
feel of the risk environment. Here are a few examples:
Brian A. Will’s List
1. Creeping requirements
2. Requirements or developer gold plating
3. Low quality of released software
4. Unachievable schedule
5. Unstable tools causing schedule delay
6. High turnover
7. Friction between developers and customers
8. Unproductive office space

Dr. Barry W. Boehm’s List
1. Personnel shortfalls
2. Unrealistic schedules and budgets
3. Developing the wrong functions and properties
4. Developing the wrong user interface
5. Gold plating
6. Continuing stream of requirements changes
7. Shortfalls in externally furnished components
8. Shortfalls in externally performed tasks
9. Real-time performance shortfalls
10. Straining computer science capabilities

Chester Simmons’s List
1. Program risks
2. Schedule risks
3. Cost risks
4. Technical risks
5. Supportability
6. Development risks
7. Communications
8. Engineering database
9. Program plan
10. Concurrent engineering trick

Reference: Applied Software Risk Management, Ravindranath Pandian, 2006

گزیده:

Modeling Principle:
Models are not right or wrong; they are more or less useful.
Martin Fowler, Analysis Pattern

آفرينش اشياء(Object Creation) به عنوان يكي از موضوعات مهم در طراحي به شكلي با موضوع جذاب معكوس‌سازي كنترل و تزريق وابستگي مرتبط است. مناسب ديدم برخي منابع مفيدي را كه در اين زمنيه وجود دارد، در اينجا ذكر كنم.

Inversion of control, or IoC, is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to the traditional architecture of software libraries.

Dependency injection (DI) in Computer programming refers to the process of supplying an external dependency to a software component. It is a specific form of inversion of control where the concern being inverted is the process of obtaining the needed dependency.

References:
– Inversion of control (IoC)
– Dependency injection (DI)
– Inversion of Control Containers and the Dependency Injection pattern
– Java: Spring Framework
– .NET: Unity – Dependency Injection and Inversion of Control Container
– .NET: The Unity Application Block

گزيده:

Patterns are a starting point, not a destination. Martin Fowler, Analysis Pattern

برگرفته از : کسب و کار نرم‌افزار

تا به حال لیست‌های متفاوتی از بهترین و تاثیرگذارترین کتاب‌های کاربردی مهندسی نرم‌افزار منتشر شده است. آنها با تفاوت‌هایی ناچیز، دارای فهرستی مشترک هستند یعنی اگر هرکدام ۱۰۰ کتاب را فهرست کنند دست کم ۹۰ مورد بین همه آنها مشترک است، البته تفاوت‌هایی هم در رتبه‌هایی که به کتاب‌ها داده می‌شود وجود دارد.
چند روز پیش دوباره به چنین لیستی برخوردم و پیوند دادن به آن را خالی از لطف ندیدم.
پیش از ادامه یادآور می‌شوم که خود بر آنم که یک مهندس کامپیوتر خوب، باید انگلیسی را بسیار خوب بداند و کتاب‌ها را به زبان اصلی بخواند. اما نکته‌ی تاسف باری که باز ذهن من را به خود مشغول کرد این بود که تقریبا هیچکدام به فارسی برگردانده نشده‌اند (دست‌کم تا آنجا که من می‌دانم) بسیاری از این کتاب‌ها کلاسیک هستند و با گذشت سال‌ها از انتشارشان هنوز بسیار پرکاربرد هستند.
با وجود اینکه بازار ترجمه کتاب‌های کامپیوتری در ایران داغ است (گذشته از این نکته که بسیاری از آنها دارای ترجمه‌هایی با سطح بسیار پایین هستند)، هنوز این کتاب های بسیار اساسی و مورد نیاز صنعت کامپیوتر ترجمه نشده‌اند. امیدوارم مترجمان خوب این حیطه کمی دست از ترجمه کتاب‌های سطحی و تکراری دست برداشته و به سراغ این کتاب ها بروند.
این لیست را در اینجا می توانید مطالعه کنید.

گزيده:
مصمم شويد كه كارى بايد صورت گيرد، سپس راه انجام آن را خواهيد يافت . آبراهام لينكلن