From: "Randy W. Sims" Date: 2004-09-17T18:32:18+09:00 Subject: Re: Want a regular Ruby Quiz? (long) I don't know how others feel, but I would love to see everyone using the same list. The perl-qotw list is already filled with ruby, python, scheme, haskell. The advantage to having one list is that you can study different approaches to solving a particular problem. Procedural vs OO. Functional vs imperative. etc. To me that's one of the most exciting things about the list. Of course, there is a problem in that a greater burden is placed on the summarizer(s), because there are potentially more solutions to examine and because the summarizer must be able to evaluate solutions in multiple languages. If you do go seperate ways... James Edward Gray II wrote: > I'm a fan of short, but regular programming "challenges" or "quizzes". > I've seen a couple of others express the same sentiment here and even on > the new Ruby Forum. Given that, I thought I would seriously gage interest. > > Main Question: I can spare the time to organize and run a Ruby Quiz. > Would you, the Ruby community, like to have that? > > I'll outline my thoughts about how it should work below. If you > disagree with my ideas, speak now or forever hold you peace. If you > have ideas you would like to add, please do. This is a group effort. > > As far as format goes, I figure we would follow somewhat close to Perl's > Quiz of the Week in that we would have one quiz each week. A quiz would > be sent out at some point in the week and followed up by a summary later > in the week. Then the cycle would repeat. > > I see little value in the Perl Quiz's Regular/Expert distinction though, > so I would drop that. When we thought up a tougher problem, our quiz > would be tougher and when we didn't it would be easy. Different > problems are different difficultly to different coders anyway. If one > question doesn't appeal to you... Well, enjoy the week off. Agreed. On perl-qotw sometime regular quizes are arguably as "advanced" as the expert quizes. In fact, the limitations sometimes make them more challenging. > I'm thinking we would keep the quiz on this list. I would prepend a > [QUIZ] to the front of question and summary subjects, for clarity. I > could place a reminder in the quiz questions for people posting > solutions and discussion to do the same. I would disagree. ruby-talk is already a very high-traffic, wide-ranging group. It would be difficult to track the solutions as they're posted, and the solutions can sometimes be long, making it more onerous for those poor souls still using dial-up. ;-) Use a seperate mailing-list please (and not a stinking web-forum :p ). There are several places that host such lists (cheap or free). > I'm offering myself as the fallback source of questions. I would add a > footer to the quiz messages, inviting people to submit questions > directly to me. When quiz time rolls around, I would choose a > submission or provide one of my own. The community would be strongly > encouraged to submit questions as I'm not a Ruby expert. I imagine I > would stumble across an interesting topic from time to time, and a dull > one at least as often. Be warned. > > As for problem difficultly, I have only a general guideline in mind: > The problem should be relatively quick to solve. I left that vague on > purpose. Everyone has different amounts of time to spare and ultimately > it must be in the question writer's hands. But if you want people to > actually work you're quiz, you should probably try not to overwhelm > them. TopCoder often has interesting questions that can be solved in > under an hour and I solved this week's Perl Quiz (in Ruby) in a little > over thirty minutes. The occasional problem that takes a couple of > hours for the average coder may be acceptable, but the main goal would > be to keep it brief. If you want to submit an involved problem, try > adding some basic framework code to the question and see if you can > leave just the interesting part to "fill in". This is very very difficult to gage. Some programmers are faster (which is not to say better) than others. Some have more expertise in certain areas. It's really hard to think of a good guidline here. Estimated size of the result my be a fair measure, but there is a lot of variation possible there also. > Again, I would be the fallback guy on summaries. When you submitted a > question, you would be expected to state whether or not you would like > to do the summary. If there's not a volunteer, I would do it to the > best of my ability, which certainly won't be perfect. The community > would be expected to chime in with corrections and comments as needed. > > I feel the summary is the primary reason to host our own challenges. We > can examine submissions and solutions from a Ruby standpoint. That > would be our main goal, to share interesting Rubyisms and thusly learn > more Ruby together. > > A final issue I'm undecided on: Perl's Quiz has a "grace period" (60 > hours) before solutions SHOULD be posted, to allow people time to think > the problem through on their own before they examine the solutions of > others. Rot13 encrypting solutions would probably have about the same > level of security, just to throw out a Usenet-like alternative. It's > strictly custom and not enforced, but it works more often than not. I'm > interested in hearing what others think about this. I think the grace period works well (and is easier). Some might argue against a grace period, but I think it is good in that it discourages speedy solutions, where people start competing to be the first to post. > Again, this is an idea in the making. Now is the time to support it, > question it, condemn it, and/or add to it. All opinions will be > considered and a quiz will be implemented if a vocal majority seems to > want it done. > > Thanks for your time. > > James Edward Gray II