This month's newsletter is brought to you by …
MailChimp gives you the power to engage customers & grow your company your way.
Welcome to the August 2016 DaniWeb Digest
This month we are going to start with a guide for anyone thinking about posting a question on DaniWeb. Pritaeas originally wrote this for members of the old 'PHP' forum, when DaniWeb had a forum-based structure. He has now re-written it to apply to all programming questions, indeed any questions that you want to post on DaniWeb. Can we politely suggest you read it, it will help us to help you and stand the best chance you can of getting the answer you seek.
Read This Before Posting A Question
Before you ask
Read our Forum Rules.
Engage your brain! We understand that running into a problem can turn off the rational centers of the brain, but please sit back and think for a bit about your problem before running off to find help. All too often a little common sense is all you need.
Search the official manuals. Usually, the official manual contains a lot of examples and comments, it is likely your issue has come up before. It is also likely there is a manual in your own language, making it even easier.
Search the forum. If you're having a problem, chances are good that someone else has had the same problem. Please search the forum for existing answers before starting a new thread. Nothing is more irritating to a long time member than answering the same question for the umpteenth time because someone didn't use the forum's search feature. See the section "Available Code Snippets" below, perhaps your question may be answered by one of them.
Search the web. Even if the same question hasn't been asked on our forum, it may have been asked somewhere else on the web. Search engines are incredibly powerful, and they won't flame you about wasting their time if you ask a dumb question.
Composing a good question
Don't hijack an existing thread. If you searched the forum before asking and the help provided in an existing thread did not solve your problem, then your problem is different enough to justify creating a new thread.
Create a meaningful thread title. So you've searched and haven't found anything that fits your problem? Great! We can help, but you need to peak our interest with a thread title that briefly describes your problem. Many members browse the topic list and choose which threads to post in only by the title. Oh, and for future reference, "<some topic> Help", "<some topic> Question", or any variation thereof does not describe your problem. We're well aware that this forum is about web development and the majority of threads are asking questions or need help.
If you don't know what the problem is, create a title that tells us what you're trying to do (as opposed to how you're trying to do it). For example: "Trying to convert an string to a float".
Ask a question that can be answered. Do not ask "What's wrong with my code?", "Why doesn't this work?" or anything else that does not give us useful information.
We're not psychic. Please organize your thoughts and provide as much information as possible to get us onto the same page. If we have to play 20 questions just to get enough information to help you, your question is more likely to go unanswered.
Post your code. If we don't know what you did, how can we possibly help? Use the CODE button so your formatting is preserved. See markdown help.
Trim your code down as much as possible. Looking through pages of irrelevant code will not expedite things.
If we can't follow your code, it's difficult to help. We don't care that you're still working on it. If you want us to read it, it must be readable.
Explain what the code is supposed to do. If we don't know where the target is, how can we help you hit it?
Explain what actually happened! If we don't know where the arrow went when you shot it, how can we tell what went wrong and how far from the target you are?
If your code generates an error, post the full error message. Indicate clearly which line in the error message compares to which line in your code snippet (both don't always match exactly).
Do not ask for code. We are not a coding service. We will help you fix your code. If anyone posts a complete working solution for you, they are enabling cheaters. If you use that code you are a cheater.
Do not bore us with how new you are. We can tell by your code. Do not apologize. We were all new once, and unless you are completely brain dead you will get better.
Do not ask us to "take it easy on you".
Do not say "I don't know what's going on". That's obvious since you posted for help. Use your time wisely and explain as best you can.
Do not post your requirements and nothing else. We view that as a lazy do-nothing student that wants us to do their work for them. That's cheating and we will be hard on you.
Do not tell us how urgent your problem is. Seriously, for us there is no urgency at all. Many that can help will ignore any URGENT or ASAP requests.
If you don't understand an answer, try to figure it out before asking for clarification. Use the same tools from the "Before You Ask" section.
Try not to take replies personally. Many frequent posters on DaniWeb will cut right to the chase and not worry about making you feel good about yourself. This is not intended to give offense; it's simply the fastest and most direct way to solve the technical problem at hand.
If someone is being excessively rude, please report them with the "Flag Bad Post" button. Do not take matters into your own hands by replying in kind. Reacting to rudeness with rudeness is likely to result in all parties being punished.
This 'sticky post' also contains an excellent list of manuals and documentation which can help you with your programming queries, you can find them here.
The guide is a living thing, an ongoing and dynamic project. As such, Prit has started a discussion thread here where members with something useful to add can, erm, suggest it. You are respectfully requested not to just reply with links etc, but rather provide a reason for adding the resource or making the change. Link only replies will be ignored, but you can use the comment/voting system if you like in order to agree or disagree with someone else's suggestion and Prit will take these into account when coming to his conclusions.
Finally, here at DaniWeb HQ we would like to thank Prit for his hard work in putting this together, off his own back as a volunteer moderator, with the sole aim of helping the community to function better. If you ever ask yourself why certain people get promoted to moderator status at DaniWeb, then this attitude is the primary reason...
The small question
Welcome to the newsletter feature where we address one of those questions that have a really easy answer. This month we look at software related career postings on DaniWeb.
panduranga_1 asked: "Is there no section for asking programming career questions on Daniweb?"
To which the simple answer is yes, there is. Such questions can be asked in the programming section and tagged with 'career' to identify it as a careers query.
The big question
The bit differs from the 'small question' bit above by addressing an issue that the DaniWeb community has been talking about in greater depth and taking a peek at the discussion. This month we are looking at 'Building a Java converter' in which Violet_82 started things by asking: "I thought I'd build a simple converter, something that allows me to convert from, say, Km to miles and so on. The framework I will use is Vaadin but it will still be Java anyway. So, I just thought I'd see if anybody has some good suggestions really. This is how I think I could go about it. The UI class will obviously hold the GUI stuff, so no need to talk about it. I will have another class, converter.java which will have a list of options as radio button selection, something like
stultuske replied: "I hate to tell you, but if you are planning to use a UI framework (Vaadin) to implement business logic, you should first learn basic OO principles." To which JamesCherrill agreed "I'm with stultuske on this one. Looking at your posts here you are trying to do way too many things at the same time. Stop messing about with frameworks and code repositories and concentrate on mastering the basics of Java coding."
The OP accepted that this was 100% right, but unfortunately "I have to use that framework, whether I want it or not, because that's what they use at work and I have to get more and more familiar with it, and pretty quickly. And so I thought that a converter wouldn't be too difficult to implement. As you probably know, I also need to practice Java and I thought I'd combine the two things together."
To sum up a very long reply from AssertNull "I usually LIKE having a convert button. Makes me feel like I am in control." The OP admitted that a button usually makes them feel more in control and if big enough is OK in touch devices. That said, JamesCherrill said that he would rather not have a button when there's no need for one. "If you have difficult validation then OK, but otherwise you just make things more cluttered and slower" he said.
It took a little while, and some more discussion back and forward, but the OP eventually built the converter v1.0 and put the code up in the thread. You can see it here, along with how the big question continued...