New Portal Launched: PatternsCentral.Com

Discussions

News: New Portal Launched: PatternsCentral.Com

  1. New Portal Launched: PatternsCentral.Com (52 messages)

    ObjectVenture Inc has launched a new online community that aims to be "your center for all things patterns".

    PatternsCentral is a portal website and supporting e-newsletter aimed at the growing community of architects, designers, and developers using pattern-based development for enterprise and web-based applications.

    Citing research indicating surprisingly strong adoption of pattern-based development by visitors to the company's free patterns tutorials (www.objectventure.com/tutorials), company founder and CEO, Dana Kaufman, said ObjectVenture is encouraged by how this adoption of patterns technology would affect sales of the company's flagship product, ObjectAssembler 2.5 Enterprise, whose core technology centers on the use of patterns in J2EE application development.

    There were some interesting results from a user survey showed that:

    "20% of our visitors are new to patterns, 24% have read about patterns and want to learn more, 35% use patterns occasionally, and an encouraging 19% use patterns whenever possible."

    Check it out: http://www.patternscentral.com

    Threaded Messages (52)

  2. Hi all,

    It was really required to have a dedicated portal for patterns as all J2EE
    Development is moving towards pattern based development.

    It is beginning of new era.

    Cheers,
    Abhijit
  3. This is retarded[ Go to top ]

    Patterns have offered nothing but confusion, and empty jargon, they are a waste of time, and resources. For proof, one only needs to look ay the myriad of snake oil sales men, and lazy academics who wish to cash in on this diseased coy. They offer nothing to the field, but more process and new methodologies, which everyone should agree are useless. They threaten to canonize the current cookbook, cut and paste, "where's the sample code" style of development that passes for expertise. If an employer, or prospective employee mentions the word "patterns" it better be followed by " are hard to find that can match my ugly tie"... otherwise ****'em.

    The most promising side of patterns was the vocabulary they would bring along, but that has been squandered away with the plethora of definitions and variations on such simple concepts as a factory, builder, and adapter. Now nobody knows what the **** you are talking about, because the names have been so overloaded. Secondly, what passes for a pattern is not even a "Best Practice". Most likely it was thought up by some sales engineer and thrown in the latest white paper. In this particular case, you are going to be told how to code by an instructor that has never written a single line of production code, and whose primary qualification is clicking the button to advance to the next ppt slide.

    Lastly, we move on to the sorry state of J2EE patterns in general. They are crap. It is easy to critique the amount of code needed to implement even the simple patterns listed in the J2EE patterns book, most importantly they fail to justify themselves. Nobody seems willing to admit that the core of most ui patterns, MVC, is a shame, an ill defined, useless notion. And what passes for a "Model" in the same book ignores the integrity of the data, and undermines caching. Following this advice results in projects that take years to build, megabytes of shitty code, and developers who can't think for themselves or tie there own shoe, because they have been spoon feed what to write all day.
  4. This is retarded[ Go to top ]

    Whoa buddy! Why don't you tell us what you really feel ;-)

    Of course patterns are over-hyped. You could say the same about OO, Java, .NET, XML, SOAP and on and on. But to go from "they are over-hyped" to "they're @#$%*&! useless" is just a bit silly.

    Patterns are fundamental (Factories, Proxies, Singletons, Builders, Iterators are used everywhere). Most programmers don't even think "Hey, I'm using a pattern" when they use patterns anymore, they just use them. To attack them as a whole is stupid. Its like attacking 'data structures' or 'algorithms'.

    As for MVC, I have personally found it very powerful. You can rant against if you like, but by default you must use some strategy for web development; page centric processing (PHP, ASP, JSP), n-tier processing (MVC, 3-tier), other??. Page centric has major maintainability problems - accessing the DB directly from a page just seems like an accident waiting to happen, that's why I use MVC, but whatever, each to his own.
  5. This is retarded[ Go to top ]

    whether you like patterns or not, you have to admit that the primary use of the 'MVC Architecture' is to fill up the first three chapters of most java books (and over 50% of every document ever written about Struts) in description and deference to former Smalltalk programmers. It's worse than the 'History of Unix' chapter I've read ten thousand times in every other computer book.
  6. MVC Architecture[ Go to top ]

    aaron evans writes " whether you like patterns or not, you have to admit that the primary use of the 'MVC Architecture' is to fill up the first three chapters of most java books (and over 50% of every document ever written about Struts) in description and deference to former Smalltalk programmers."

    There is some truth in this. There is a lot of tendency for authors to elaborate on 'hackneyed' things like 'History of Unix', 'MVC Architecture' etc. They can refer to some other resource and carry on with the real subject. No, they will fill up some chapters on "What is the Internet?", "What is the Browser?", before they embark on the subject of the book. Real waste of paper.
  7. Ironically...[ Go to top ]

    ...the PatternsCentral site is built in PHP.
  8. Hugh?[ Go to top ]

    Hi Mark,

    ...the PatternsCentral site is built in PHP.

    And your point is? I suppose you were expecting a J2EE-based sight, right? Although I happen to be rooted in the Java space at the moment, PatternsCentral is not specific to Java. Perhaps you don't like PHP. Okay - that's nice. I guess I can't please everyone because PHP isn't everyone's favorite language. I think the quality of the site speaks for itself.
  9. Waste of time[ Go to top ]

    Frankly, I think this site is virtually worthless as it is now. Seriously, what does it offer over other sites that have pattern information? At least other sites offer lists of patterns where you can get detailed information about them. I would like to see a site with a library of documented patterns, where registered users could post comments/experiences about them. This way, when I'm looking for a pattern I can quickly learn what people have to say about that pattern from their experience which will would be of great help (since many patterns look better on paper than they do in real code). A site with some generic info, a forum, and a "pattern of the month" is pretty useless to me.
  10. Really?[ Go to top ]

    Frankly, I think this site is virtually worthless as it is now. Seriously, what does it offer over other sites that have pattern information? At least other sites offer lists of patterns where you can get detailed information about them. I would like to see a site with a library of documented patterns, where registered users could post comments/experiences about them. This way, when I'm looking for a pattern I can quickly learn what people have to say about that pattern from their experience which will would be of great help (since many patterns look better on paper than they do in real code). A site with some generic info, a forum, and a "pattern of the month" is pretty useless to me."


    I think it offers quite a bit, and I think you should give it a chance. It is a *brand new* site, so don't be so quick to judge!

    The Pattern of the Month column is aimed at presenting and teaching some of the most fundamental patterns. There is another column for summarizing conversations in pattern forums around the pattern community at large. A number of other columns and articles will come online soon. I can't understand why you don't find this useful. Don't you find the articles published here at TheServerSide useful? Jeez...

    The library of patterns is coming, so please check back from time to time. We'll offer a repository of existing ones and also put out new ones that you may find of interest. Most of them will be in article form, but we are working to build an XML-based repository in the future that will allow you to do some pretty crazy things when searching for and applying patterns. Anyway, feel free to post your opinions about what such a repository should be like to be useful. A number of members have already contributed interesting articles that we will post soon. Why not join them? You maintain the rights to everything you let us post.

    Alos take a look at our links section. Over time it will become the largest searchable set of pattern-related links anywhere. It allows ratings and other useful features. And this is only the beginning. From Web blogs to reviews to downloads, we are working hard to build up content for everyone to enjoy FREE of charge. We wouldn't mind having our members add their own favorite links, and to get involved in a myriad of other ways as well.

    Lastly, the forums on PatternsCentral are really among the best you'll find functionality-wise. And as we grow, you'll start seeing much more activity. I encourage everyone to participate. We actually have a group of people monitoring the forums who can help you answer questions about patterns, where to find certain types of resources, or just to bounce things off of in general.

    *So you see, we already have much to offer. And we are working very hard to make this a vibrant community. It's not often that an effort like this comes along, so please give it a chance and contribute!*

    Best regards,
    Bill Willis
    Director, PatternsCentral
    "Where Patterns and People Meet"
  11. Final comments[ Go to top ]

    Bill, I'll keep my eyes peeled for that patterns repository. However, you need to understand that even if you have great forums their greatness is dimished by not having a library of patterns. The reason is that if people are talking about the decorator pattern and I don't know what that pattern is, then it doesn't help me much to read some guy spew how great (or not so great) it is. Granted, I could go to other resources and find that information but I shouldn't have to. If you're presuming that all the people who go to your site already know all the patterns out there, then fine. Otherwise, you need to provide that library (which you said you are working on). Good luck with your site,

    Marc
  12. Final Comments[ Go to top ]

    I'll keep my eyes peeled for that patterns repository. However, you need to understand that even if you have great forums their greatness is dimished by not having a library of patterns.

    Thanks for the input, and I agree. That information (at least the fundamental patterns) will be there soon, but also remember that there is plenty to talk about other than specific patterns. I hope you'll join us from time to time.

    Best regards,
    Bill Willis
    Director, PatternsCentral
    "Where Patterns and People Meet"
  13. Final Comments[ Go to top ]

    Bill, I had a peek at your web site and took the "Patterns" challenge quiz. I did learn a thing or two on patterns on your site.
  14. Final Comments[ Go to top ]

    Bill, I had a peek at your web site and took the "Patterns" challenge quiz. I did learn a thing or two on patterns on your site.

    Hi Anil,

    That's great! Make sure you also check out the Software Design Pattern Tutorials here when you have some time to explore:

    http://www.patternscentral.com/modules.php?name=Forums&file=viewtopic&t=9

    This is an ongoing series of tutorials that explores what patterns are, why they are useful, and how you can use them to help develop better software systems. Please let me know what you think. The next tutorial in the series should be out in 2-3 weeks, so check back every once in a while...

    Best regards,
    Bill Willis
    Director, PatternsCentral
    "Where Patterns and People Meet"
  15. The Great Pattern Run[ Go to top ]

    If we go to the basic defenition of pattern it says pattern is a solution to a recurring poblem. Most people tend to forget the last two words. They are more centric to use of pattern rather than solving the problem and this tends to the usage of patterns where it is not intended. So in that case why blame patterns ? One has to spend some time in identifying the problem and then check whether a particular pattern can solve the problem. But in most of the cases it is blindly selecting some patterns put it here and there and finally tell I have used the patterns, but after using this pattern is the archictecture giving the right perforamce etc are not being considered and hence the system fails if the site usage increases etc.
    So Maintaining a repository which tells what this pattern is intended to be used and its limitation is of utmost importance. I hope PatternsCentral will do this. To startwith I think the site is pretty good. All the best.
  16. A car without wheels[ Go to top ]

    Well, I visited the site - nothing but forums that I can get elsewhere and a little other documentation.

    I understand that this is a *new* site, but what's the point? Were you in a rush to go public or something?

    Launching a web site on patterns, without listing at least the fundamental patterns, is like launching a car without wheels, and inviting everybody to have a drive...

    It has potential, but right now it's just hype.
  17. A car without wheels[ Go to top ]

    Well, I visited the site - nothing but forums that I can get elsewhere and a little other documentation. I understand that this is a *new* site, but what's the point? Were you in a rush to go public or something? Launching a web site on patterns, without listing at least the fundamental patterns, is like launching a car without wheels, and inviting everybody to have a drive...

    It has potential, but right now it's just hype.


    Shall I take that as cautious optimism? You must understand that a site like this is a huge undertaking (just the infrastructure alone), and we are not always in control of when the lights come on and we get noticed. I urge everyone who is looking for copious amounts of content to be just a little patient. Our next batch of articles is due out in the next 2-3 weeks. And as I mentioned earlier, we are working on the repository of patterns you seek. I don't think you will be dissapointed.

    But just to be sure, why not hop on over to PatternsCentral and tell us what you would like to see in such a repository? Why not also add your favorite links so that others may benefit, review your favorite pattern book, or do any number of things that PatternsCentral allows you to do? Remember, this is intended to be a community where people share ideas and opinions - not just a static repository of patterns or a place where only the select few are able to sound off.

    Do you think sites like TheServerSide burst on the scene with the loads of great content you see today? Nope. This site grew strong and healthy over time thanks to the community that formed around it. That is the only way PatternsCentral will succeed, so even if you find this site just merely promising, why not be an active member and help it become the place you would like it to be?

    I hope you'll at least give us a chance...

    Best regards,
    Bill Willis
    Director, PatternsCentral
    "Where Patterns and People Meet"
  18. A car without wheels[ Go to top ]

    Launching a web site on patterns, without listing at least the fundamental patterns, is like launching a car without wheels, and inviting everybody to have a drive...

    >
    > It has potential, but right now it's just hype.

    I agree.. In the moment I use:

    1. the HTML version of GOF book
    2. Rational repository of patterns (very good)
    3. java.sun.com (many J2ee patterns)

    I think its enough for now, but I would like to see a repository of patterns categorized in different domains.

    I also thought the user interface of the site very poor, and I would like to see it running in java/jsp/servlets and not PHP.
  19. A car without wheels[ Go to top ]

    I also thought the user interface of the site very poor, and I would like to see it running in java/jsp/servlets and not PHP.

    Could you be more specific? Most of the responses I have gotten on the site look and feel have been positive. Perhaps I could address some of your issues. What's wrong with PHP? Although the company that is initially sponsoring this site is heavily involved in the Java market, this site is not Java specific. I hope we see a bunch of .Net folks and people working on various other platforms as well. I also hope we see people from outside the software industry get involved.

    I think its enough for now, but I would like to see a repository of patterns categorized in different domains.

    We plan to provide such a beast, but we will need input from the community to make it happen. I will start a new topic over there for this purpose, so please stop by to add your thoughts if you get a chance. Thanks.

    Best regards,
  20. A car without wheels[ Go to top ]


    >I hope we see a bunch of .Net folks and people working on various other >platforms as well. I also hope we see people from outside the software >industry get involved.

    My suggestion:

    3 clicks is the maximum necessary to reach a pattern.

    But if you will work with .net, java, j2ee, analysis patterns... etc.. Make sure to make easy to reach a pattern, beacause you will have a large tree to categorize all.

    Doesnt matter if interface is ugly or not, just make easy to reach a pattern.

    I thought difficult to read info in your site, beacause of a lot of information. You need to add constrast between different kinds of information.

    I wish you good luck
  21. The Great Pattern Run[ Go to top ]

    You make a fairly good case for patterns.

    Personally, I think they're useful, but mostly because it gives a common name to a complex thing. The problem I see is that people attach _far_ too much importance on patterns - just like they do with things like unit tests.

    The fact is, when the original design patterns book came out, most experienced engineers had already figured out the same things on their own. Given an OO language, it's fairly easy to deduce things like Singleton, Command, etc. The main value derived from the book was giving a central definition, and pattern names that quickly became accepted.

    But I think there's a backlash because people overvalue them and see them as something they're not. Patterns are a common vocabulary - period. They aren't guides, or "best practices", or anything like that. At most, generally accepted pattern definitions are a laundry list, a dictionary of various design approaches. Like words in a dictionary and their definitions, all they you are the basics of the language of design. Experienced word smiths - or software designers - learn how to put those things together to achieve their desired affect, and further know when it makes sense for them to break the rules (sort of the software equivalent of poetic license).

        -Mike
  22. The Great Pattern Run[ Go to top ]

    I agree that too much is made of patterns in the sense that they're not that big a deal, really. They can be extremely useful and I think that the way the GoF authors originally defined them in their book is even more useful. I don't understand the backlash because to me it's like someone saying that some pretty basic things like domes and arches in real-world architecture are useless.

    Although I concede your point that the fact that the original patterns in the GoF book established a common vocabulary, I still think that the main power of that book was defining a method of pattern documentation. Because patterns are defined with the forces that make them necessary, the steps needed to implement them, and consequences of their use, they provided a way for people to determine for themselves if and when they should be used. I think to apply any pattern as some sort of recipe on a card or paint by numbers solution is pretty dangerous. But because of the method of documentation, developers can get a chance to understand the reasons why a particular pattern is useful and come up with some sort of solution, usually using only portions of the pure pattern implementation. I guess I look at them as more of someone teaching you how to fish rather than giving you the fish. Maybe I'm alone in this.

    That's probably why I still think it's a good idea for people to list a bunch of different patterns, because people face all kinds of odd circumstances in solving their development problems every day, and if there's a chance someone has encountered the same situation, I'd like to learn from their experience. At the very least, even if I don't like their solution, it helps to read their approach to gain insight into the particulars of your own situation. Of course this also means that to me, anyone who says that a pattern, particularly an esoteric J2EE one, is something to be considered with great awe and reverence, is someone to be ignored. REmember that even the GoF patterns can be changed; they're not holy writ. The authors even support this "teach a man to fish" view of their approach by often discussing implementation variations in the pattern notes.

    And let's also remember that even the GoF patterns aren't "solutions" in some grand sense; they're targeted to very specific implementation details. I don't think I'm making some grand visionary statement about the business problems I'm solving on a project when i use a singleton pattern. I'm just using a pattern to solve one very specific implementation detail. I think patterns should be viewed as tools. With that view, they become less "sacred" and can be used in whatever manner seems best to the developer. Then maybe all this backlash effort can be used on something else more worthy of derision.
  23. The Great Pattern Run[ Go to top ]

    <Drew>
    Although I concede your point that the fact that the original patterns in the GoF book established a common vocabulary, I still think that the main power of that book was defining a method of pattern documentation. Because patterns are defined with the forces that make them necessary, the steps needed to implement them, and consequences of their use, they provided a way for people to determine for themselves if and when they should be used. I think to apply any pattern as some sort of recipe on a card or paint by numbers solution is pretty dangerous. But because of the method of documentation, developers can get a chance to understand the reasons why a particular pattern is useful and come up with some sort of solution, usually using only portions of the pure pattern implementation. I guess I look at them as more of someone teaching you how to fish rather than giving you the fish. Maybe I'm alone in this.
    </Drew>
    No, you're not alone at all. I think this is exactly the right attitude to take regarding the use of patterns. I find the use of patterns to be most effective when they are used as an example of how to solve a specific problem, not when we look at them as "the way". One of the biggest benefits to using patterns to teach software architecture and design is exactly the one you mentioned--the fact that the pattern itself encompasses the forces that led to its use, the issues involved in its implementation, and the consequences of its use. This I believe is the true benefit of the use of a pattern in a given situation.
     
    ...
     
    <Drew>
    And let's also remember that even the GoF patterns aren't "solutions" in some grand sense; they're targeted to very specific implementation details. I don't think I'm making some grand visionary statement about the business problems I'm solving on a project when i use a singleton pattern. I'm just using a pattern to solve one very specific implementation detail. I think patterns should be viewed as tools. With that view, they become less "sacred" and can be used in whatever manner seems best to the developer. Then maybe all this backlash effort can be used on something else more worthy of derision.
    </Drew>
    Another important point. I think a lot of the backlash comes from the fact that the use of design patterns has taken on a culture of its own in some circles. There are lots of folks who seem to take the stance that patterns have become some cure-all for proper software design. "Oh, you need an Adapter here". I also see a lot of folks who post "patterns" to this site and others who appear to be more interested in defining a pattern than defining a solution :) One thing that I think gets lost in all the hand-waving and navel analysis that some folks tend to do over stuff like this is that design patterns are an incredibly useful learning tool, particularly for less seasoned designers. One of the biggest advantages of the GoF book and somewhat so the J2EE patterns book is that they give you information when you don't know where to start. Sometimes its useful to just read through the descriptions, and compare the information with the problem you are trying to solve--often there is enough of a similarity in order to spark the design of a solution. In my experience there are very few "a-ha!"'s under these circumstances, but there are a great many "Hmmmm...."'s that can result. We all realize at some point in our lives that there is no substitute for experience, and I think that is perhaps the biggest benefit of the use of patterns. They are A way, (not THE way), and in a lot of cases, thats just what we need.

    Best,

    Brian Neal
    Educational Services
    BEA Systems, Inc.
  24. Final Comments[ Go to top ]

    I looked at the Software Design Pattern Tutorials and it is a good step at evangelizing Patterns.

    Books On Patterns

    Hope patternscentral.com site be a central repository of information on patterns. Amen!
  25. Give me a break...[ Go to top ]

    "Portal" seems to indicate, to me at least, that the subject is so live and constantly changing that you need to access a site several times a week to keep up. IMO, design patterns are not even close to fitting this definition. I would think that a good design pattern comes up one a year or so. The GoF guys put several decades' worth of design efforts into one book. In J2EE it seems someone is making up some new design pattern every week. All this attention to design patterns seem highly exaggerated to me. It seems like people think "good design" and "design patterns" are synonyms. In fact, if you want to improve your design, you should study a great many things, only one of them being design patterns. But you don't see "OO design" portals popping up.

    As a regular site PatternsCentral may be nice, I only got a shallow look so far. But I'll be visiting it once every six months, not one a day.

    Gal
  26. Design Patterns[ Go to top ]

    It has been my experience that a shop that speaks at length about design patterns (in an interview) is a shop that is not letting their people or their head guide their designs. I think they are using design patterns as a cruch for poor people or bad code or bad requirements. As said before pattern adherance is not good or even great design by itself.
  27. Design Patterns[ Go to top ]

    Well said Jim.
  28. Design Patterns[ Go to top ]

    It has been my experience that a shop that speaks at length about design patterns (in an interview) is a shop that is not letting their people or their head guide their designs. I think they are using design patterns as a cruch for poor people or bad code or bad requirements. As said before pattern adherance is not good or even great design by itself.

    That is unfortunate, but you will certainly admit that this happens with things other than patterns. Does this make patterns a bad thing? No. It just means they are being misused. I *do* agree that design pattern adherence is not good design. Patterns *help* us design/implement and should be used with care - just as with anything else. But to ignore patterns is to waste valuable experience. Hopefully PatternsCentral will help people use patterns effectively as one of many tools of the trade.

    Don't let other people's ignorance keep you from using patterns effectively...

    Best regards,
    Bill Willis
    Director, PatternsCentral
    "Where Patterns and People Meet"
  29. Design Patterns[ Go to top ]

    Jim:

    Can't comment on your experiences, but our company has successfully used patterns so that we don't have to re-explain things that have been done before. This allows us to focus our resources on the more novel (higher risk) aspects of a solution.

    I suppose that could be considered a crutch. But like having to have a car to get to work, it is widely accepted. And we do talk about patterns at length in our interviews.

    What we do is hard. Using patterns has made my job a little easier.
  30. Design Patterns[ Go to top ]

    I think patterns are very useful.

    Their use shows up every time I have to write an architecture doco. Just the fact that a pattern has a name means it can be talked about and documented as part of the architecture.

    Design Patterns have achieved the "holy grail" of reuse that OO was suppose to bring us.

    Design Patterns usually follow the form of encapsulating what varies and providing extension points.

    Again they have names and you can talk about them.

    Whats not to like?

    tx

    Matt
  31. Give you a break?[ Go to top ]

    "Portal" seems to indicate, to me at least, that the subject is so live and constantly changing that you need to access a site several times a week to keep up. IMO, design patterns are not even close to fitting this definition. I would think that a good design pattern comes up one a year or so.

    I think they most certainly are. One look at the resources scattered all around the Web should give you a good idea of just how much is already available. I frankly got tired of remembering where everthing I found was. That is one of the reasons PatternsCentral was created - to attempt organizing pattern resources and provide a central place to get what you need.

    There are already hundreds of useful design patterns out there, not to mention thousands of useful resources. When you also factor in patterns at the architecture and code (idioms) level, you'll get lost in them all. And why would patterns be exclusive to software? Patterns are everywhere - in fact, we humans are constantly attempting to form/learn them every day and then apply them. Patterns in other fields could even help us improve the way we design software. This is not hype, it is just a really simple fact.

    Patterns aren't some difficult 10-headed monster that will save the world one day. They are merely a way to describe, communicate, and reuse best practices.
    This is a simple but very powerful concept.

    People are finally beginning to recognize the benefits of patterns and the great well of experience they encapsulate. However, those same people are having difficulty approaching them and using them correctly. I hope efforts like PatternsCentral will help in this respect and separate the hype from reality.

    It seems like people think "good design" and "design patterns" are synonyms. In fact, if you want to improve your design, you should study a great many things, only one of them being design patterns.

    I think they actually go hand in hand in that patterns help you improve your design based on the experience of others. How is that a bad thing? Would you rather reinvent the wheel every time you design or implement a software system?

    As a regular site PatternsCentral may be nice, I only got a shallow look so far. But I'll be visiting it once every six months, not one a day.

    I think you may want to dig deeper and see what more it offers. If you wait six months, you'll miss a tremendous amount of content and community discussions that I'm sure will be very relevant to what you are doing. And why not contribute? Go to the forums right now and speak your mind. Do you think patterns are a load of horse hocky? Go ahead and say it, and then we'll have a constructive discussion that may just change your opinion.

    Best regards,
    Bill Willis
    Director, PatternsCentral
    "Where Patterns and People Meet"
  32. Give you a break?[ Go to top ]

    Bill,

    I think we have different sets of definitions for what design patterns are. I do look around on the Web, and I have not seen many real design patterns that I didn't know before. I've seen many specific solutions to specific problems, but not generally recurring best practices like Singletons, Factories, Decorators, etc. In fact I maintain, and have for years, that the Design Patterns section here in TSS has 90% of specific solutions, 9% of useless ideas that are just plain bad, and 1% design patterns.
    I don't think that having a general repository of solutions to problems is a bad idea. Not at all. But calling all of these things design patterns and bombarding the community with hundreds of names and words to describe *highly specific* solutions is just plain counter-productive in my opinion. If you changed the name I wouldn't mind it at all :) But then most developers won't look in your site.

    The problem with these "design patterns" (I'm not referring to the ones in your site because it isn't full yet, I'm talking about TSS for instance) is that you take some semi-useful design ideas, and call them design patterns. Then you go on to say how great design patterns are in establishing better communication and reuse between developers, giving real design patterns as convincing examples. The fact is, Singletons provide better communication between developers. "Super Remote Interface Extended to Session Facade" does not. Factories make for excellent code reuse. "Bluddy Big Transactions: How to deal with deadlocks" does not. These are actual quotes, and I could go on with "Reusable Data validation using EJB 2.0 Home Methods and BMP", "Creating Dependent Entity Beans using Auto-PrimaryKey-Gen" and so forth. I think you would agree that these articles describe what seem to be fairly specific solutions. Maybe good solutions, but still fairly specific. These so called patterns do next to nothing for reuse, and if a fellow developer tried to communicate his design to me using these patterns I'd run away screaming. This is the absolute majority of design patterns I have seen on the Web. If your site will manage to bring in a new pattern each week which is a *real* design pattern, I'd come back every week to look at it. I just don't believe this is possible, even if you replace "a week" with "a month", or two, or three.

    Gal
  33. Give you a break?[ Go to top ]

    Hi Gal,

    The problem with these "design patterns" (I'm not referring to the ones in your site because it isn't full yet, I'm talking about TSS for instance) is that you take some semi-useful design ideas, and call them design patterns.

    You know what? I agree with you in general. There is a tendency to call just about everything a pattern. I still maintain; however, that there are numerous documented patterns out there - I wish I had the time to load every decent one I know about in one night. And there will be many more valuable ones (as opposed to contrived) coming from all corners of the globe. In fact, this will be a problem in the near future - sifting through all of that great stuff to find the gem you need. This is where repositories will come in very handy, and we are working hard to build such a beast and get it ready in time.

    Of course, even one pattern could have many potential applications. This is also something useful to document and for others to learn. If you take a look at our first patttern of the month, you'll see that the Composite pattern (of GoF fame) is actually split into several different kinds of composites.

    And please don't think that hatching patterns is all that PatternsCentral aims to do. The most important function of PC is to bring people together to discuss patterns (in general) in a public forum. The second most important thing is to educate people in the proper use of patterns. We would also like to push the boundaries of patterns R&D, which includes developing tools and technologies for supporting the use of patterns in software architecture, design, coding, processes, etc.

    If you are just looking for new patterns, that's fine. I'm hoping you won't be disappointed. In any case, I hope to see you there from time to time.

    Best regards,
    Bill Willis
    Director, PatternsCentral
    "Where Patterns and People Meet"
  34. Give you a break?[ Go to top ]

    Hi Gal,

    >
    > The problem with these "design patterns" (I'm not referring to the ones in your site because it isn't full yet, I'm talking about TSS for instance) is that you take some semi-useful design ideas, and call them design patterns.
    >
    > You know what? I agree with you in general. There is a tendency to call just about everything a pattern. I still maintain; however, that there are numerous documented patterns out there - I wish I had the time to load every decent one I know about in one night. And there will be many more valuable ones (as opposed to contrived) coming from all corners of the globe. In fact, this will be a problem in the near future - sifting through all of that great stuff to find the gem you need. This is where repositories will come in very handy, and we are working hard to build such a beast and get it ready in time.

    I guess we have different expiriences on this point. My expirience has taught me that real and useful design patterns are hard to come by. If your site will sort through the posts to find real pattern posts, that would be very useful (I've asked for that on TSS many times). But my guess is 90% of the submitted material won't make it, and you'll wind up with a small library of pretty well known patterns. I think this is a good thing. Patterns should be something developers learn and use to talk to each other, and developers can't learn hundreds of names and patterns, and even if the could it would only complicate the discussion. Having tons of usefull patterns is improbable theoretically and counter-productive practically.

    >
    > Of course, even one pattern could have many potential applications. This is also something useful to document and for others to learn. If you take a look at our first patttern of the month, you'll see that the Composite pattern (of GoF fame) is actually split into several different kinds of composites.
    >

    No doubt about that. The GoF patterns each have applications in many contexts. That's why it is a *recurring best practice*. Something that is only useful in one context can't by any definition be called a pattern.

    > And please don't think that hatching patterns is all that PatternsCentral aims to do. The most important function of PC is to bring people together to discuss patterns (in general) in a public forum. The second most important thing is to educate people in the proper use of patterns. We would also like to push the boundaries of patterns R&D, which includes developing tools and technologies for supporting the use of patterns in software architecture, design, coding, processes, etc.
    >
    > If you are just looking for new patterns, that's fine. I'm hoping you won't be disappointed. In any case, I hope to see you there from time to time.
    >
    > Best regards,
    > Bill Willis
    > Director, PatternsCentral
    > "Where Patterns and People Meet"

    Gal
  35. Give you a break?[ Go to top ]

    Having tons of usefull patterns is improbable theoretically and counter-productive practically.

    Hi Gal,

    I appreciate your feedback. In my experience, a set of core patterns usually develops in each domain of knowledge, so I agree with you there. This will really be an experiment, and we intend to hold the patterns we collect to a high standard. Part of this process will be presenting them in a public forum before adding them to our repository. I hope you'll be there to comment.

    Best regards,
    Bill Willis
    Director, PatternsCentral
    "Where Patterns and People Meet"
  36. Give you a break?[ Go to top ]

    Bill,

    > This will really be an experiment, and we intend to hold the patterns we collect to a high standard. Part of this process will be presenting them in a public forum before adding them to our repository. I hope you'll be there to comment.

    If pattern posts would be properly scrutinized before making it into the
    patterns repository then your site will definately go into my favorites. Standard forms, XML descriptions of patterns, hyperlinks between related patterns and usecases, etc can be very usefull. But if the content is no good, none of it will help. If you want my feedback, the most important thing for a patterns site is maintaining high stanrads for pattern posts. The rest (UI, added functionality, UML diagrams, ...) is minor.

    Good luck.
    Gal
  37. Software For Your Soul[ Go to top ]

    I must admit that day by day I am getting disillusioned by the industry as never before. I entered the field because I enjoyed computers, software, solving problems and all that. When I was a kid I had no PC yet wood and chisel would gratify my desire to create and tweak. I am seriously considering going back to wood. Software was very appealing to me. But I was young and single. I had the time, the curiosity, energy and patience.

    Today I am angry with the industry. I get home exhausted and drained out. I work on my attitudes and dispositions so that it won’t spill into my home and affect the great looking wife I enjoy so much.

    I still like computers and building things. But I am not sure it’s worth anymore. Everything I touch is ridden with bugs. EVERYTHING. Whatever tool I use, whatever methodology, does not live up to its promise. It does not matter who does it. Microsoft or Peoplesoft, open source or hidden source. If I could only spend my time writing software but so much of my time and energy goes into configuring and fixing configurations, switching API’s or environments, trying to figure why this or that stopped working out of the blue and so forth. Even today my XP IBM X20 crashed twice within 10 minutes. IDEA lost all personalization that takes time to redo. Resin’s httpd.exe would not find java.lang.Object anymore so I write a .cmd script instead. The rt_core JSTL library would not take a runtime value in one of it’s tag attributes in whatever serlvet container. Scaling a Photoshop image ends up blurred when pasted into Word. Tried to use png format but Robohelp won’t take that. Word stubbornly indents numbered lists even if I remove the automatic markup. Yes, I need classes for that. Whatever. These are some of the past two days. I wish software would be brought to the same level of scrutiny as cars or food and banned if not according to promise. Software giants should be sued like the tobacco industry for their fraudulent products.

    Does software improve my life? Is it bringing value to my workday? Yep. Screw Microsoft and Sun alike. I’m thinking of my road back home. Not the highway – the tire marks in the road make me sea-sick. So much for patterns.
  38. Software For Your Soul[ Go to top ]

    Grace to those who believe without seeing.
    Why haven't you changed your career when they say programming is
    evil's plot. Why did you wait until you see it yourself. Oh, poor soul.
    Open your mind and see the brighter world out of your box.
    End of your engony is near.
    Be aware that sweeter may be devil's seduction.

    I, who refuse to see outer world, would keep my soul in the deepest
    trench of the world of computer and watch the whole world to sit lame
    on the bugs.
  39. Reliability and Specialization[ Go to top ]

    On software reliability: Check out the now-famous essay by Joel Spolsky: "Good Software Takes 10 Years: Get Used to It", at http://www.joelonsoftware.com/articles/fog0000000017.html

    On Specialization: In old-fashioned environments like IBM mainframes and As/400s there is/was a separation of duties: the application programmer and technical support specialists, who handled infrastructure. Howevermuch they may be despised (especially by those who have never used them), this DID enable the app programmers to spend almost ALL of their time working directly on the customer's problem. (And the proprietary environments did (seem) to allow for software that was reliable - most mainframers could not imagine the circumstances that you describe / endure.)

    I think that the new technologies' intermixture of the application world with the enviroment (the application IS the environment!?!?) can make life challenging . . . sometimes almost too much!

    Best - gh
  40. Software For Your Soul[ Go to top ]

    <f g>
    Today I am angry with the industry. I get home exhausted and drained out. I work on my attitudes and dispositions so that it won’t spill into my home and affect the great looking wife I enjoy so much.
    </f g>

    Quit your bitchin'. And by the way, she's not that great looking.
  41. I do not know why some people think that patterns are a waste of time and just another thing to learn.

    You can easily get by with a small number of patterns. Most patterns have evolved from some core patterns anyway. You will also find that you have used some patterns without knowing. It really does not hurt to see what other people have come up with.

    The real problem is to know when to apply patterns. It is not always obvious that you should use some spesific pattern to solve a problem. Maybe this new site will help to find how other people solve problems.
  42. Wow! A lot of negativity about patterns. I can't say that I expected that. But then, a lot of people moaned about the idea of a round earth, too.

    OK, that was a little inflammatory. I can understand people's frustration. It seems to come from several sources:
    1) People are tired of buzzwords. I know I am. If "Design Patterns" is becoming a buzzword (buzzwords?), which I guess it is, I can understand why people would be wary.
    2) People are tired of hearing about all of these great "patterns" that aren't applicable to most people's work. There are a lot of strategies out there and best (or worst) practices that people use. If any of those get formally documented, in a fashion similar to what the GoF proposed, then technically speaking, they're patterns. That means that there's a lot of crap out there for people to sort through. Anyone could throw together a description of a practice and call it a pattern; the real question is, will anyone else find it useful? I think a lot of the J2EE patterns out there exist solely to deal with deficiencies in the J2EE architecture, and so anyone outside the J2EE world would look at them and scratch their heads.

    Overall, though, I think it's pretty ridiculous to discount the idea of patterns based on either of these reasons. Good, useful patterns are formal statements of good, useful practices and should be shared as much as possible. Do you think it would be wise as a real-world architect to ignore the notions (patterns) of "arch" or "dome" just because you're sick of people talking in buzzwords? If you'd never used an arch or a dome and were scratching your head trying to figure out how to solve something that either of those patterns could solve, you'd be grateful if someone said, "here are several patterns that may help you. Here's a definition of the purpose of the pattern, the forces that led to its necessity, and the implications of its use, both positive and negative." Or at least I hope you would. Or at least, barring that, I'd hope I'd never walk into a building you designed.

    Some others in this discussion were claiming that obscure, fine grained pattern definitions weren't really patterns. Not true. It doesn't matter how obscure or useless they are; if their authors formally document the description, forces, consequences, etc. of a practice or strategy, then a pattern has been born. Whether or not it serves any useful purpose to anyone else in the world is another story. The more commonly known patterns (Factory, Singleton, etc.) are only recognized as "real" patterns because they're patterns that are so universally applicable. Hell, I've got a "pattern" for crossing the street so that I minimize time waiting for traffic lights to turn green. I could publish it and it would be a real pattern so long as I document it thoroughly but I sincerely doubt anyone would use it.

    I think people fail to realize that the concept of patterns isn't that complicated. A pattern is nothing more than a formal statement of a best practice or strategy. Anything can be the source of a pattern. If you document it sufficiently, it's a pattern. I'm actually grateful for sites that post a bunch of them. Even if most of them are crap (which they are), every once in a while, a good one comes out, or at least one that addresses forces that I might be dealing with on a particular project.
  43. But then, a lot of people moaned about the idea of a round earth, too.


    That’s actually bullshit. And bringing up an analogy does not help your point. http://info.greenwood.com/books/0275959/027595904x.html

    >I think it's pretty ridiculous to discount the idea of patterns based on either of these reasons.

    Look drew, you can argue with YOUSELF all day, but what about for the reasons I brought up...

    - They provide no value, as the vocabulary has been tainted by divergent, chaotic and unclear writing.
    - As they are all to often created by people who never write systems.
    - They promote the all to common practice of not thinking.

    >Good, useful patterns are formal statements of good, useful practices

    the terms "Best Practice" and "Pattern" no longer have any relation to "useful" practice. You show me a "good" pattern, and I'll show you a much better description of the same problem in clear and readable format. The solutions proposed by most all patterns can be deduced by a child.



    >Do you think it would be wise as a real-world architect to ignore the notions (patterns) of "arch" or "dome" just because you're sick of people talking in buzzwords?

    Well that’s just silly... "Dome" is no more a pattern then "Chair" is. And if you want to talk about architecture, and the origin of patterns... C. Alexander has already given up on the idea, and after a few failed projects, concedes that building using patterns produces strange eclectic and unappealing designs.


    > I'd hope I'd never walk into a building you designed.

    Well **** you too.

    >Not true. It doesn't matter how obscure or useless they are

    Well, some people like to derive value from what they read.


    >I could publish it and it would be a real pattern so long as I document it thoroughly .


    And that’s a good reason why the term "Pattern" is now useless.


    >I think people fail to realize that the concept of patterns isn't that complicated.... Anything can be the source of a pattern

    Wow... we really need more Patterns buffs in this world. Why don't you write a pattern on the problem of dealing with people like me, and your solution?

    I'll help you get started, by showing you my pattern for dealing with people like yourself.


    Problem:

    You encounter an "expert" who uses analogies to make points, refers to patterns, best practices, probably has a really good tan, and most definitely is talking nonsense.

    Solution:

    If you work with the "expert" and don't agree, simply nod your head and just do the right thing, as soon as they leave the room. Otherwise, be an *******, and don't accept any of that slimy double talk they like to use.


    Context and Example Problem:
    Drew McAuliffe puts up a PHP discussion board, and some other crap like a poll. And then tries to claim he is doing something great for the software community, most likely, Drew is unaware of his ignorance.

    Context and Example Solution:
    Your reading it.
  44. Context and Example Problem

         Anonymous Anonymous Simply Bitches
         Anonymous Anonymous Simply Whines
         Anonymous Anonymous Simply is Anal

         Proof of the pudding is his two lame posts on this subject
              # 81638
              # 82159

         Expressed in his own childish manner.

    Context and Example Solution:

         One way ticket to France! Maybe he can get someone to listen to him over there with his senseless bitching.
  45. WOW! You need to be hosed down my friend. Sorry your girlfriend dumped you or whatever else caused your bitterness.

    Quite frankly, I think you are
    a) COMPLETELY unprofessional
    b) Pretty misguided
    c) Offering no value to the rest of the community here.

    I admitted that my "round earth" analogy was a bit much and wasn't very appropriate. But I'll continue to stand by everything else I said. I believe that if I were to come to your company in the little fantasy you described, I would have a hard time knowing where to begin with my "analysis" of your systems because it sounds to me like you haven't the slightest idea of what you are talking about. COntinue writing your PHP and VB code, oblivious to what the rest of the world does. Continue reinventing the wheel repeatedly; I'm sure that the people paying you to develop would appreciate the fact that you're wasting their time and money when you do so.

    I think you have the WRONG idea of what a pattern is. A pattern isn't something special or buzzwordy. It is A DESCRIPTION OF HOW TO SOLVE A COMMON PROBLEM, documented with information you'd need to know to determine whether or not it would be useful to you. There are good patterns out there, like "arch" and "dome". I don't think you'd just start building everything with an arch or a dome just because you read about those patterns. If you really knew what you were doing (again, that seems to be a big leap in your case), you'd be able to discern whether or not a particular pattern was useful to you in a given situation.

    You say
    "You show me a "good" pattern, and I'll show you a much better description of the same problem in clear and readable format."
    Ok, all you've told me is that you'd rewrite the pattern. No big deal. If a pattern isn't well written, it becomes harder to understand when it's appropriate or how to use it. So please, turn yourself loose on the pattern community. Rewrite all of the patterns you see into a clear and readable format. If you are as skilled at this as you say, you can write a book and I'll probably buy it, because I agree that sometimes the patterns aren't documented well enough.

    Patterns are really advice to the developer, suggestions on how and why a particular strategy might work. They're not languages, they're not development tools. They're advice. There's a lot of advice out there. If you can't tell the bad from the good, that's no reason to criticize the idea of a consistent method of giving advice. It just means you lack the experience or intelligence to sift the good from the bad.

    Oh, and I'm sorry all the other kids hated you.
  46. Drew,

    I understand your point about patterns being a very broad thing, but I think it is placed out of context in this particular discussion. I could just as well argue that patterns don't really exist in an epistemological sense. That can be debated, but it's hardly relevant for this discussion forum, which is a software discussion forum. I could then say "well, you talk about patterns as if they surely exist, so you must be ignorant of epistemology". By taking things that I said about patterns, and applying a much broader definition to them, you are literally twisting my words. Here is a post I made in the discussion following the "Detail Tab Presentation Tier Pattern" pattern on December 04, 2002:

    <gal>
    Well, what is or isn't a pattern depends on one's point of view. You can call just about any software design a pattern.
    When I'm talking about design patterns, I'm talking about a certain POV, the one described in most design pattern books. Here is an excerpt from "Design Patterns by GOF" (IMO the definitive guide):
    "Point of view affects one's interpretation of what is and isn't a pattern... The design patterns in this book are *descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context*."

    Gal
    </gal>

    Everything I say about design patterns in this thread relates to the definition I quote from the GoF book above. Certainly there are other, broader definitions. But if you intend to use these definition, please don't also say that design patterns facilitate better communication between developers, help reuse of code, improve overall design, etc. To do that a pattern has to be slightly more specific than "something whose author documented the description, forces and consequences of". Something that is utterly obscure and useless, as you put it, doesn't do these all these great things. My problem is that people say "you should use design patterns because they do all these great things", and then give you useless paterrns that do nothing but give you a headache. I could call my spoon a knife, but its still not gonna help me slice a steak.

    And finally, I don't have one bit of negativity regarding design patterns. In fact I take a good deal of my time to study them, document them and discuss them. I just don't think it is a subject that merits an entire portal, and I fear that it will be filled with a lot more hype than useful patterns. If they prune the patterns for real useful ones the site will be very useful, IMO, but it will also be too small to be called a portal and collect a big user community and live discussions, etc.

    Gal
  47. I understand your point but I think even those patterns that you dismiss in your previous posts are still design patterns. They're just design patterns that don't offer you a lot of value. I'm not going to make a blanket statement that design patterns will improve code reuse, promote better design, or anything like that. That's because only GOOD design patterns will do those things, and only if they are used in situations that are appropriate.

    I think if we want to play with semantics, then I would still say that "what is or isn't a pattern depends on one's point of view" should really be reworded as "what is or isn't a GOOD pattern depends on one's point of view." What you are regarding as "design patterns" are really the use of a broader definition of patterns at a very specific point of abstraction and granularity in the design process. There are a number of other patterns that can be applied at various other levels of granularity For example, most of the J2EE design patterns people speak of are at such a fine-grain that they are only applicable to VERY specific circumstances; that, coupled with the fact that they're usually used to counter some issue or weakness in the J2EE architecture makes them susceptible to a lot of criticism, and probably rightly so.

    I would agree with you if you say that the number of GOOD, universally useful design patterns wouldn't be enough to fill a portal. However, the benefit (IMHO) of the patterns movement (I'm hesitant to say that for fear of stirring up buzzwordy issues) is not the patterns themselves but the manner in which they are communicated. The beauty of the GoF "Design Patterns" book is that it established a manner in which best practices could be communicated, offering background, forces descriptions, and consequences of use. With that, people not only got a set of useful practices but also a very good, concise way in which to determine if their use was appropriate. If each best practice was described in a prose chapter rather than in the formal pattern method that they used, it would be a lot harder for people to sift through the book and determine what was appropriate.

    That said, while I agree that the current number of useful patterns wouldn't necessarily be sufficient to fill a portal, I think that a portal that has a constant influx of new patterns is still extremely useful. Because of the example set by the GoF for pattern definition, it is easy for me to sort through new patterns and quickly determine whether or not they offer me any value. You'll sift through a lot of chaff, but eventually the good ones will rise to the top (how's that for mixing agricultural metaphors?). At some point someone will have encountered some of the same forces you may be dealing with on a particular project, so if I can find a pattern dealing with those forces, it might be useful to me (or at least get me thinking of a solution of my own). Maybe everyone else in the world may scoff at the use of a pattern for dealing with some esoteric issue, but if I'm struggling with that issue myself, I'd be glad for a little assistance.
  48. \Binyamini\
     And finally, I don't have one bit of negativity regarding design patterns. In fact I take a good deal of my time to study them, document them and discuss them. I just don't think it is a subject that merits an entire portal, and I fear that it will be filled with a lot more hype than useful patterns. If they prune the patterns for real useful ones the site will be very useful, IMO, but it will also be too small to be called a portal and collect a big user community and live discussions, etc.
    \Binyamini\

    I concur completely. Given the capabilities of modern OO languages, I think there's only a relatively small number of design patterns that are general enough to be designated as such.

    I'll also go on to say that much of the backlash against patterns is due to post-GOF authors and consultants (and the deadly combination of author/consultant). There are far too many such people who write as if they are "authoratative" in the matter, when in fact our industry is still young enough that we're still groping in the dark. And their forcefulness in insisting (in writing, or on a job site) that their list of patterns are definitive and must be followed at risk of catastrophic consequences leaves a bad taste in alot of developers' mouths, my own included.

    And sadly, sites like this one often end up with self proclaimed experts performing their own version of demagoguery.

        -Mike
  49. "And finally, I don't have one bit of negativity regarding design patterns. In fact I take a good deal of my time to study them, document them and discuss them. I just don't think it is a subject that merits an entire portal, and I fear that it will be filled with a lot more hype than useful patterns. If they prune the patterns for real useful ones the site will be very useful, IMO, but it will also be too small to be called a portal and collect a big user community and live discussions, etc."

    Hi Gal,

    As I have probably said before (please forgive me), this portal is not just about providing a repository of patterns. It is intended to be a community that focuses on patterns in software and outside of software. There is plenty to talk about and learn, and I think there will be many more sites like this in the future. One thing I would certainly like to see addressed are the misconceptions about patterns, because we certainly have a lot of them on display here. One of our goals is to set the record straight by separating hype from reality. Once people understand what this patterns thing is all about (not rocket science by any means), they can get down to the business of learning and applying.

    But going back to the repository (which, again, will only be one aspect of the site), I think there are many more useful patterns than you suppose. From what I can tell, you are mostly hung up in design patterns and idioms of software. That's like spending your life in the kitchen and not getting out of the house to explore the world you live in. And just because many of them don't specifically relate to software doesn't mean they won't be useful to you (and certainly others).

    And one final thing: now that some quality patterns have been and continue to be introduced, it would be nice to start helping people make use of them and their known applications. The way they are documented today and related is not very useful IMHO, and this is one of the primary reasons they have not formally gone mainstream. Myself and others have been researching ways to bridge this gap, and I'm sure some of this stuff will end up on PatternsCentral. I supposed it is okay for people to dismiss patterns as bunk, but that's fine by me. I have had great success with them in my work, and I think they have enormous potential in helping people build much better software - much of which still remains untapped.

    As for how well PatternsCentral will fare in the future? Who knows. In contrast to what others have stated, there is plenty to cover and discuss. In fact, I am completely overwhelmed at times by the amount of quality information currently available on patterns. It will take me and those involved with the site a while just to catalog all of the good stuff already there (remember, not just patterns in a catalog - you know... articles, links, discussions, books, interviews, etc.). While we plod away, we are also working on a lot of new content that is not hype and very useful. The discussions will also be very good - in fact, we already have some good ones going.

    Come on Gal, I know there is a pattern hugger in there waiting to come out of the closet. Why fight it? ;-)

    Bill Willis
    Director of PatternsCentral
    "Where Patterns and People Meet"
  50. Bill,

    I'm not hung up on software desing patterns. But that is what I figured was the main topic of your site based on what's allready there. Of course there are patterns in music, literature, and other topics as well. But collecting them all in a "patterns" site seems odd to me. Sort of like collection in one site all written material that uses the letter 'a'. It's not the correct categorization IMO. When I want information on composing music, I'll go to a music site and hopefully find, among other useful resources, descriptions of patterns like canons anf fugues. When I want to write literature I'll go to a literature site. "Patterns", with no specific topic, is not of any interest to me except pure academic interest. A community discussing "patterns" in general would inadvertably be split into communities that discuss patterns in specific topics, because that is what they need practically, and that's what they understand. I can't imagine a musician being interested or even understanding software design patterns, or a sofwtare engineer with no music background understanding musical patterns.
    Anyway, my opinion still remains that patterns do not merit a portal. I just don't want to read about them every day or even every week. The idea of a "general" pattern portal and a "general" pattern community with no specific topic seems unrealistic to me, and I also can't see what the advantages of such a "general" site would be for anyone except academia folks. I would also be surprised if the site does get populated with patterns from such varying topics. From everything I can see in the site now and from where you advertise it, it seems to me that the main focus, even if it is unofficial, is software engineering patterns. Isn't it?

    Gal
  51. Hi Gal,

    A community discussing "patterns" in general would inadvertably be split into communities that discuss patterns in specific topics, because that is what they need practically, and that's what they understand. I can't imagine a musician being interested or even understanding software design patterns, or a sofwtare engineer with no music background understanding musical patterns.

    Really? So I assume you haven't read any of Alexander's works. After all, who cares about all of that building architecture crap. That is a pity, because he had a HUGE influence on us software guys. I am of the belief that other disciplines can learn much from each other regarding the patterns they mine and employ. You can continue living inside your box, but I prefer to employ a more open-minded approach. Alexander's works resonated with me in a way that nothing in our industry has. I am now looking at some of the theories people have regarding patterns of nature, and guess what: I feel that tingle again - I intuitively see applications in software. My advice to you and everyone else out there: Don't discount the teachings of other disciplines, because through them we often advance our own.

    I would fully expect communities within the community to form, but the point is that we all share a common goal: Further developing this thing called patterns. In doing so, we all need to look over the walls between us and share ideas and experiences. I am thankful that some of us software guys did this with respect to Alexanders theories. There will be others.

    From everything I can see in the site now and from where you advertise it, it seems to me that the main focus, even if it is unofficial, is software engineering patterns. Isn't it?

    There is a high concentration on software patterns right now because that happens to be the interest of those who launched the site. And for the record, I am not interested in academic exercises unless they lead to practical applications. Academia is a fertile ground for conceiving ideas, but these ideas are useless unless we can make something of them. There is much to discuss and accomplish in the area of software patterns alone (not the least of which is correcting the widespread misuse of patterns), so I strongly disagree with your position. However, you are free to put out your own opinion, even if I feel it is misguided.

    If you can't see the advantages of this site, then I can do no more than put them right in front of you (some yet to come). All you need to do is open your eyes.
  52. What happened to the portal?[ Go to top ]

    Both www.objectventure.com and www.patternscentral.com are gone without any notice.

    I wonder what happened?
  53. What happened to the portal?[ Go to top ]

    I've heard from somebody who was involved with patternscentral.com.
    Unfortunately ObjectVenture has gone out of business and the patternscentral.com site became administratively too difficult to keep up on its own.