On Wed, Apr 22, 2009 at 07:46:48PM +0200, Stef Mientki wrote: > With Python you can do everything, so why do you need Django or > Web2Py at all ?
Django and web.py (which is the topic of this thread; I'm not sure where you got Web2Py from) *are* Python. They are Web application frameworks written in Python. Anyone who is interested in Django but unfamiliar with the term should see the first section of the first chapter of _The Django Book_, "What Is a Web Framework?" [1]. [1]: <http://djangobook.com/en/2.0/chapter01/> > I'm struggling with the same question [about Django vs. web.py] for > about 2 months now. It seems that a lot of people who answered this > question, all have a lot of apriori knowledge of webdesign. > Questions in my opinion are never stupid, only answers can be. That depends on how you look at things. I've been referencing Eric S. Raymond's essay, "How to Ask Questions the Smart Way" [2], on this list recently, because I'm not used to such poorly-worded or lazy questions being asked on a technical mailing list. Programmers don't typically operate like this, and it's odd to see subscribers to a technical list put up with so much wasted time and effort. I assume it's a result of lots of participation from people who are new to programming and unfamiliar with netiquette and the ways of hackers. For those who don't know, Mr. Raymond, frequently referred to as ESR, is well-known in hacker circles and the Free Software movement in general as the maintainer of the Jargon File [4] and author of "The Cathedral and the Bazaar" [5]. [2]: <http://www.catb.org/~esr/faqs/smart-questions.html> [3]: <http://www.catb.org/~esr/faqs/hacker-howto.html> [4]: <http://www.catb.org/jargon/> [5]: <http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/> Following is a quote from from ESR's essay "How to Ask Questions the Smart Way" that illustrates the difference between stupid and smart questions: >> Use meaningful, specific subject headers >> >> On mailing lists, newsgroups or Web forums, the subject header is >> your golden opportunity to attract qualified experts' attention in >> around 50 characters or fewer. Don't waste it on babble like "Please >> help me" (let alone "PLEASE HELP ME!!!!"; messages with subjects like >> that get discarded by reflex). Don't try to impress us with the depth >> of your anguish; use the space for a super-concise problem >> description instead. >> >> One good convention for subject headers, used by many tech support >> organizations, is "object - deviation". The "object" part specifies >> what thing or group of things is having a problem, and the >> "deviation" part describes the deviation from expected behavior. >> >> Stupid: >> HELP! Video doesn't work properly on my laptop! >> >> Smart: >> X.org 6.8.1 misshapen mouse cursor, Fooware MV1005 vid. chipset >> >> Smarter: >> X.org 6.8.1 mouse cursor on Fooware MV1005 vid. chipset - is >> misshapen >> >> The process of writing an "object-deviation" description will help >> you organize your thinking about the problem in more detail. What is >> affected? Just the mouse cursor or other graphics too? Is this >> specific to the X.org version of X? To version 6.8.1? Is this >> specific to Fooware video chipsets? To model MV1005? A hacker who >> sees the result can immediately understand what it is that you are >> having a problem with and the problem you are having, at a glance. >> >> More generally, imagine looking at the index of an archive of >> questions, with just the subject lines showing. Make your subject >> line reflect your question well enough that the next guy searching >> the archive with a question similar to yours will be able to follow >> the thread to an answer rather than posting the question again. >> >> If you ask a question in a reply, be sure to change the subject line >> to indicate that you're asking a question. A Subject line that looks >> like "Re: test" or "Re: new bug" is less likely to attract useful >> amounts of attention. Also, pare quotation of previous messages to >> the minimum consistent with cluing in new readers. The whole essay is worth reading. I'll quote two more sections, the introduction and "Before you Ask", for those who are unwilling to simply go and read the whole thing. Note that "hacker" is used in the traditional sense (one who enjoys finding clever ways to make computers do things) and not the more popular but inaccurate sense (one who causes mischief with computers; those are crackers, not hackers). >> Introduction >> >> In the world of hackers, the kind of answers you get to your >> technical questions depends as much on the way you ask the questions >> as on the difficulty of developing the answer. This guide will teach >> you how to ask questions in a way more likely to get you a >> satisfactory answer. >> >> Now that use of open source has become widespread, you can often get >> as good answers from other, more experienced users as from hackers. >> This is a Good Thing; users tend to be just a little bit more >> tolerant of the kind of failures newbies often have. Still, treating >> experienced users like hackers in the ways we recommend here will >> generally be the most effective way to get useful answers out of >> them, too. >> >> The first thing to understand is that hackers actually like hard >> problems and good, thought-provoking questions about them. If we >> didn't, we wouldn't be here. If you give us an interesting question >> to chew on we'll be grateful to you; good questions are a stimulus >> and a gift. Good questions help us develop our understanding, and >> often reveal problems we might not have noticed or thought about >> otherwise. Among hackers, "Good question!" is a strong and sincere >> compliment. >> >> Despite this, hackers have a reputation for meeting simple questions >> with what looks like hostility or arrogance. It sometimes looks like >> we're reflexively rude to newbies and the ignorant. But this isn't >> really true. >> >> What we are, unapologetically, is hostile to people who seem to be >> unwilling to think or to do their own homework before asking >> questions. People like that are time sinks — they take without >> giving back, and they waste time we could have spent on another >> question more interesting and another person more worthy of an >> answer. We call people like this "losers" (and for historical reasons >> we sometimes spell it "lusers"). >> >> We realize that there are many people who just want to use the >> software we write, and who have no interest in learning technical >> details. For most people, a computer is merely a tool, a means to an >> end; they have more important things to do and lives to live. We >> acknowledge that, and don't expect everyone to take an interest in >> the technical matters that fascinate us. Nevertheless, our style of >> answering questions is tuned for people who do take such an interest >> and are willing to be active participants in problem-solving. That's >> not going to change. Nor should it; if it did, we would become less >> effective at the things we do best. >> >> We're (largely) volunteers. We take time out of busy lives to answer >> questions, and at times we're overwhelmed with them. So we filter >> ruthlessly. In particular, we throw away questions from people who >> appear to be losers in order to spend our question-answering time >> more efficiently, on winners. >> >> If you find this attitude obnoxious, condescending, or arrogant, >> check your assumptions. We're not asking you to genuflect to us — in >> fact, most of us would love nothing more than to deal with you as an >> equal and welcome you into our culture, if you put in the effort >> required to make that possible. But it's simply not efficient for us >> to try to help people who are not willing to help themselves. It's OK >> to be ignorant; it's not OK to play stupid. >> >> So, while it isn't necessary to already be technically competent to >> get attention from us, it is necessary to demonstrate the kind of >> attitude that leads to competence — alert, thoughtful, observant, >> willing to be an active partner in developing a solution. If you >> can't live with this sort of discrimination, we suggest you pay >> somebody for a commercial support contract instead of asking hackers >> to personally donate help to you. >> >> If you decide to come to us for help, you don't want to be one of the >> losers. You don't want to seem like one, either. The best way to get >> a rapid and responsive answer is to ask it like a person with smarts, >> confidence, and clues who just happens to need help on one particular >> problem. >> >> (Improvements to this guide are welcome. You can mail suggestions to >> e...@thyrsus.com or respond-a...@linuxmafia.com. Note however that >> this document is not intended to be a general guide to netiquette, >> and we will generally reject suggestions that are not specifically >> related to eliciting useful answers in a technical forum.) >> Before You Ask >> >> Before asking a technical question by e-mail, or in a newsgroup, or >> on a website chat board, do the following: >> >> 1. Try to find an answer by searching the archives of the forum >> you plan to post to. >> 2. Try to find an answer by searching the Web. >> 3. Try to find an answer by reading the manual. >> 4. Try to find an answer by reading a FAQ. >> 5. Try to find an answer by inspection or experimentation. >> 6. Try to find an answer by asking a skilled friend. >> 7. If you're a programmer, try to find an answer by reading the >> source code. >> >> When you ask your question, display the fact that you have done these >> things first; this will help establish that you're not being a lazy >> sponge and wasting people's time. Better yet, display what you have >> learned from doing these things. We like answering questions for >> people who have demonstrated they can learn from the answers. >> >> Use tactics like doing a Google search on the text of whatever error >> message you get (searching Google groups as well as Web pages). This >> might well take you straight to fix documentation or a mailing list >> thread answering your question. Even if it doesn't, saying "I googled >> on the following phrase but didn't get anything that looked >> promising" is a good thing to do in e-mail or news postings >> requesting help, if only because it records what searches won't help. >> It will also help to direct other people with similar problems to >> your thread by linking the search terms to what will hopefully be >> your problem and resolution thread. >> >> Take your time. Do not expect to be able to solve a complicated >> problem with a few seconds of Googling. Read and understand the FAQs, >> sit back, relax and give the problem some thought before approaching >> experts. Trust us, they will be able to tell from your questions how >> much reading and thinking you did, and will be more willing to help >> if you come prepared. Don't instantly fire your whole arsenal of >> questions just because your first search turned up no answers (or too >> many). >> >> Prepare your question. Think it through. Hasty-sounding questions get >> hasty answers, or none at all. The more you do to demonstrate that >> having put thought and effort into solving your problem before >> seeking help, the more likely you are to actually get help. >> >> Beware of asking the wrong question. If you ask one that is based on >> faulty assumptions, J. Random Hacker is quite likely to reply with a >> uselessly literal answer while thinking "Stupid question...", and >> hoping the experience of getting what you asked for rather than what >> you needed will teach you a lesson. >> >> Never assume you are entitled to an answer. You are not; you aren't, >> after all, paying for the service. You will earn an answer, if you >> earn it, by asking a substantial, interesting, and thought-provoking >> question — one that implicitly contributes to the experience of the >> community rather than merely passively demanding knowledge from >> others. >> >> On the other hand, making it clear that you are able and willing to >> help in the process of developing the solution is a very good start. >> "Would someone provide a pointer?", "What is my example missing?", >> and "What site should I have checked?" are more likely to get >> answered than "Please post the exact procedure I should use." because >> you're making it clear that you're truly willing to complete the >> process if someone can just point you in the right direction. Again, that's from "How to Ask Questions the Smart Way" by Eric S. Raymond, which is available at <http://www.catb.org/~esr/faqs/smart-questions.html>. -- Phil Mocek --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
