Phase 2 of Design Pattern Contest StartsMonday November 22nd, 1999The first phase of the Design Patterns in Mozilla Contest has ended, and the second phase is underway with a deadline of December 5. The patterns submitted in Phase 1 can be found on our contest submission page. You can criticize the entries and use them to guide you in finding other patterns. Be sure to read the rules here. So far there has been only one contestant so it should be really easy to win some prizes! Finding patterns can be as easy as searching for them by their name with LXR. The Design Patterns book should be available in most libraries, if you do not own it yourself or cannot get it from a friend. Also, the contest is now accepting entries that contain patterns not only found in the Design Patterns book, but also those documented on the Web. This should make your hunt a bit easier. Be sure to include a link to the pattern definition in your submission. Uh... What a design pattern? Either or pick atleast one, a) People would rather be coding then finding patterns. b) People are not intrested in finding patterns from the book for the book. c) The contest has failed despite the valiant efforts to make it work. d) Some or all of the above. e) Add your own here. BTW I love the Mozilla project and the progress made thus far on Mozilla but as far as this contest goes I think D All of the factors mentioned above. I am the one contestant! Also I want to add my own entries to the list of why interest was so low. I think people don't realize how powerful design patterns are at documenting code. When I entered this contest, I had never looked at the Mozilla source code. So I did this as an exercise. I found 4 design patterns in basically one afternoon using mainly lxr and grep. Although I am not a Mozilla guru (and I don't intend to submit code in the near future) I know now some non obvious relations between different parts of the code. Once you have discovered a design pattern, there is a chance that some of the participants of one pattern particiate in an other pattern. This is what happened to me when I did a search for Observer and found a Command class. One thing about the GoF patterns is that they help you navigate the code. For example, once you know an Observer class you know that there is a Subject class that can notify the observer. You also know that there should be at least one ConcreteObserver that may query the Subject for information. Another important point. We looked at the code from one of the first milestones (I think it was M4), and some of the design patterns I found in M10 where not found in M4. A possible explanation is that since the Mozilla source code has evolved so much, I think it is likely that some of the developers are using design patterns (possibly not knowing they are design patterns, or simply not documenting them). So I don't think it's a great deal of effort to document them. It is only a bit tedious without tool support. Greg mail: knapeng@iro.umontreal.ca PS: I'm part of a group that is working on a reverse engineering environment for C++ and java. One of the unique features of this environment is that it allows the detection and visualization of design patterns. I did not use this tool for the contest because we are in the process of overhauling our C++ parser. Otherwise, I think I would have found a lot more:) We intend to use our tool to find design patterns in M11. for more info: http://www.iro.umontreal.ca/labs/gelo/Spool/ When I first thought about the contest, I thought there would be dozens of people participating, mostly because they were interested either in Mozilla or in Patterns. I thought that since it is so difficult to start hacking Mozilla, it would be much easier to find Patterns from the code. But people seemed to think otherwise. Admittedly the prize could have been better (and we have an option of upping it now). But the book is good, and it was easy to give it out as a prize because one of the authors sits in the jury. Still, I thought people would do it for the fame and not for the money. There were several reasons I wanted to organize the contest. I thought it would be fun to participate, it would create good documentation, find and fix bad design, get new people involved in Mozilla and get people to learn about patterns. The participation could have been better (you can still change that). But something is better than nothing and I am sure the contest has brought new people to Mozilla community even if they haven't participate. --Heikki Toivonen Maybe the problem is that people had to read the book in order to have a chance at winning the book. I'm still curious-- what's a design pattern? (same anon as before) to read a summary of "The Book", go to amazon.com, search for "Design Patterns" and you'll find : http://www.amazon.com/exec/obidos/ASIN/0201633612/o/qid=943350005/sr=8-1/103-8862279-8917466 or straight from the editor (Addison Wesley) : http://www.awl-he.com/titles/13933.html -- Hervé to read a summary of "The Book", go to amazon.com, search for "Design Patterns" and you'll find : http://www.amazon.com/exec/obidos/ASIN/0201633612/o/qid=943350005/sr=8-1/103-8862279-8917466 or straight from the editor (Addison Wesley) : http://www.awl-he.com/titles/13933.html -- Hervé I think of a design pattern as being any solution to a problem that is reused to the point that it becomes a pattern (I suppose this could mean that if it's reused *once*, it's a pattern). Some elementary design patterns would be event loops, searching/sorting algorithms, GUI interaction techniques. |