Related
An interviewer just asked me that question, if I was familiar with "active" statements.
I then asked if she was referring to prepared statements, and she said no, I had no other choice but to answer "I'm sorry, but I'm not familiar with them".
It seemed like it was not important at all, I still got a second interview.
However, after googling the question I haven't been able to find a reference to "active" statements.
I should have asked for the answer, but then again since it was an interview it would have not been an appropriate question.
Does anyone around here have a clue?
Thanks a bunch!
P.S. If this is not a good question for the community, feel free to close or delete the thread!
Did they maybe mean "Active Record?" That's an object-relational mapping technique, used to match model-tier code to data code, and uses automatically generated SQL statements.
Where can I find a tutorial for writing DownThemAll AntiContainer plugins in JSON?
The documentation is confusing...
Considering the fact that, five hours after you asked it, this question is already one of the top ten Google results for "DownThemAll AntiContainer tutorial", it seems unlikely that any more detailed tutorials exist.
Perhaps you can learn more by examining the source code of existing plugins or by contacting one of the plugin authors, nmaier and poke? (You need a GitHub account to use the "message" feature.)
In case anyone is still looking:
This is a nice Wiki-Tutotrial about it https://github.com/downthemall/anticontainer/wiki/Writing-plugins
however, it does not explain the fine details, to grasp how this can be applied to a specific problem
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm a computer science student finishing up my second semester of programming classes. I've enjoyed them quite a bit, and learned a lot, but it seems other students are struggling with the concepts and assignments more than I am. When an assignment is due, the inevitable group email comes out the day or two before with people needing some help either with a specific part of the problem, or sometimes people just seem to have a hard time knowing where to start.
I'd really like to be able to help out, but I have a hard time thinking of the right way to give them help without giving them the answer. When I'm having trouble understanding a concept, a code snippet can go along way to helping me, but at the same time if it makes a lot of sense, it can be difficult to think of another way to go about it. Plus the Academic Integrity section of each assignment is always looming overhead warning against sharing code with others. I've tried using pseudo code to help give others an idea on program flow, leaving them to figure out how to implement certain aspects of it, but I didn't get too much feedback and don't know how much it actually helped them out, or if it just confused them further.
So I'm basically looking to see if anyone has experience with this, or good ways that I can help out other students to nudge them in the right direction or help them think about the problem in the right way.
Have them explain their code to you.
This accomplishes several things:
First, it demonstrates that they actually have code to show you. How can they not understand something if they haven't even opened up a text editor yet?
Next, it demonstrates that they understand the code at a basic level. They could have copied it from somewhere. If they don't know the first thing about the code they have, that's a flag. (If they did copy the code, but still took the time to understand the code, then that's still academically dishonest but it's a valuable skill to use after college.)
Finally, now we're at the place where they might actually get it, with your help (or possibly even without!) If they get to the place where the hole in their understanding is (as they're explaining their code to you) and it jumps out at them, then they've solved their own problem. If they don't recognize the hole, then this is where you can give them targeted hints.
I've worked as a TA and at a CS department help desk (and helped buddies). This is what I do...
Abstract out the issue, find a related problem, then work through the related problem with them. If they can't make the connection, you can't really help them.
Edit: and refuse to help with more than the bare basic syntax if they are looking for help the day of or day before. Things should have been dealt with long before deadline. Crutching people on the day-of is not a good practice for you.
Some thoughts:
Do pair programming
Have the student (the person you are helping) sit in the chair and code something. Could be a code snippet, could be a portion of a project, anything, as long as it represents something they have trouble on. As they go, point out (not rudely) places where they may have done something incorrectly, or something that could be improved upon.
Review work done
One of the things that helped me the most was to have a peer (as opposed to a teacher or student aide) review my code. Most of the time the peer could point out places where they might have done something differently.
Make them repeat you.
I often make people I'm helping learn repeat what I just said to see if they understand it or have any questions. You would be surprised how often people don't speak up when they don't understand something.
Offer help before the project is due.
Trying to get the project done the night before it is due is a surefire way to, at the very least, not learn the concepts as thoroughly as you might have otherwise.
Don't code it yourself
Your peers will learn nothing if you do it for them.
Find other resources
An aide, a friendly professor, another one of your peers can be invaluable resources. If you find that your style of teaching doesn't mesh well with one of your peers' style of learning, point them toward someone else who might be able to help them more.
Hope for the best
You can only go so far when teaching someone; they have to want to learn.
One thing that might be helpful to your fellow students is to point to similar code in the lecture notes (or if you don't get lecture notes handed out, in your own notes). That way you're only showing them what the professor said, but doing it in a helpful way.
If another student is open to it, asking them questions about everything they've tried and why would be helpful.
Finally, consider going to your professor and asking for his or her input on what you are allowed to do and how they might suggest you help others. After all, professors have years of experience in teaching students. Even more, will you have an opportunity as an undergraduate to be a TA in future years? I got to TA as an undergraduate, and that helped me to productively use my impulses to assist others without breaking any honor codes. If you have such undergraduate employment opportunities, letting professors see you now as the helpful type will help you acquire them.
I don't think you should be helping them. I think it's academically dishonest. Also, it does them no help to have you give them answers, or even to have you be around to answer questions, since once they get to the exam (or the real world), you won't be there for them. They need to not only learn how to program on their own (which presumably you're helping them do), but also get their questions answered on their own. That means posting on places like StackOverflow. You might want to recommend that they formulate a specific question (always a good exercise) and post it on here with the "homework" tag.
When I was taking CS classes in college, there were a number of students who just couldn't code or design at all (and I'm thinking of a senior level software engineering class in particular). They also had no idea how to go about solving problems, or where to look things up, where to get questions answered, or what questions to ask. They were totally helpless because they had spent most of their undergraduate time working on their homework/projects in groups and having the more talented group members hand-hold them. Don't perpetuate this. The last thing the industry needs is more incompetent programmers who graduate with good grades to put on their resume.
Whenever I tried to teach my girlfriend how to program I did almost nothing but ask questions. (she got to the .each statement before getting bored)
Ask them question how their code works and how they think they could accomplish the task. Give them small nudges in the right direction. And never EVER type something for them. If you have another computer and type code on it to show them and show them the results, that is fine but don't over do that.
Here's the advice I give my student teachers: avoid giving answers to students. Instead, ask them questions. And make sure to ask questions that they can ask themselves in the future. For the material I teach, here are some of the questions I want all students asking themselves:
What is your abstraction?
What is an example of how your abstraction is supposed to behave? Can you show me another example?
Are there any examples of where you abstraction is allowed to fail? How should it fail on that example?
Have you tested these examples?
What is the representation of your abstraction?
How does the representation relate to the abstraction? Can you show me a picture? Can you show me in math?
What functions are allowed to see the representation? What is the contract of each function? Does the representation satisfy an invariant that the function can assume? Does each function make sure the invariant is preserved?
What does valgrind say?
One of the most common problems in teaching is determining whether the student understood you. An easy and effective way to determine if you should continue or rephrase is to have the student demonstrate their understanding by doing something closely related but not identical.
Also, since programming is essentially word problems, it's important that the student break things down into steps. I'd be asking to see their highlevel step-through before I showed them anything. Too many people get hung up in syntax and never really nail down what they're trying to do before diving in.
A general experience in explaining stuff to others is to find out where they stand first. Try to refrain from giving them solutions to problems they don't even have yet (even if you are sure that they will come across them later). In other words, don't go two steps ahead of them. If they have problems understanding call-by-value, don't explain them recursion.
As far as helping fellow students in general, I generally use the "play stupid" approach. I pretend that I know nothing about their particular assignment, and I ask them to get me up to speed on what they are supposed to be doing. I also ask them to give me a quick run-down of what they learned in class about whatever concept the assignment is about. This usually takes about 5 minutes and about 95% of the time, the other student has answered their own question by the time they finish explaining it to me. If they haven't solved it by this point, I ask them to walk me through their solution to the assignment. In doing this, they usually catch where their solution deviates from what they just said they learned in class.
As far as programming-specific help goes, I sometimes ask the other student to send me their code and I run it through a simple shell script I wrote. That script blanks out everything in the code file that is not a comment, and I give the result to the other student to read. The resulting file usually reads like an outline of their code, and a lot of times they can see where their code went wrong simply by getting the code out of the way. If their approach is completely wrong, I tell them to write an outline of what the code is supposed to do (in high-level terms) using comments; after completing this, they fill in each section of the outline with code that implements that outline step (testing each "chunk" as they go). This helps a lot of people separate the code from the algorithm (many common problems I see stem from the lack of a systematic or disciplined approach to problem solving, and this exercise helps get them on the right path).
Another method is to answer questions using a different programming language. For example, I helped several of my fellow students on Matlab projects by explaining the concepts using C, Ruby, or even pseudo-code (that read more like plain English than code). I knew that they had far more experience with other languages, so I used what they knew best to illustrate the concepts and encouraged them to try solving the problem in their "native language" first. Once they were confident that they understood the concepts, they could work on figuring out how to implement them in the target language. Having to learn new concepts while you are still learning a language makes both more difficult. This approach also helps determine whether they are having trouble understanding how to solve the problem or how to code the solution.
PSYCHOLOGICAL APPROACH
show them some popular real world APPLICATIONS (as an example) which they use day to day...written in same programming language you are trying to teach.....
explain every thing with background
give every student, considerable importance
alwaysss use colour coded syntax
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been attempting to learn programming (in C#) for a few years now. The problem I've had is that I'd know what I want to do (or what I want the program to do), but no idea on how to actually implement it. So I often wonder what it is I'm lacking. Is the mindset of a programmer somehow different, and I've yet to condition myself to that type of thinking, or do I just need to know more about syntax and what they do?
Of course, it's compounded by the fact that I have no means of taking classes at the moment.
So is trial and error the way to being a better programmer, or are there essential pieces that I presently lack?
Also, my goal is to eventually get into the Gaming Industry, and I don't know if that affects anything at this point.
By far the best way to improve your skills is to practice, practice, practice, and then practice some more. Just like an athlete gets better and hones his skills and natural abilities, the more you code the better you will get. Your best resources are going to be books and the internet--blogs, articles, websites such as SO are incredible sources of information. Google is your friend, learn how to use it effectively.
Find a problem you want to solve, and then find two or three ways to solve it. Being able to approach a problem from different angles can be an invaluable skill.
I would also recommend finding an open source project you can participate in. There are plenty of 'em out there.
Yeah, it's pretty much trial and error.
Or more accurately, research, trial, error, cry, fix, error, research, success!
Anything I want to do (that is new) I typically find by doing various searches, or I accidentally learn by participating in forums like this, and then am lucky enough to remember when it becomes neccessary.
Just dedicate yourself to research and trying "various things", and then you'll become better at it. You just need to accept that it will be difficult at first, and that that is quite acceptable and appropriate.
You'll get the hang of it. As long as you're motivated, you'll achieve what you wish.
I think the most valuable thing at this point is seeing working code in action. Get your hands on lots of working sample apps with full source that interest you. Look at the source, figure out what does what, and start to modify it!
Then try to write your own apps using similar constructs, and you'll find it much easier.
I like silky's second sentence. I agree. Just hang in there.
Find a project (small project) that you want to do, and then learn how to do it. Any project...like build a calculator or something. If you have a goal in mind, it makes it a lot easier...and it will make it easier to people to help you when you post questions so they can have a frame of reference.
Lots of google searches...and stackoverflow searches ;)
One other way that can get you started is to look at standard examples (and I'm sure you can find lots of those for C#) try and run them, understand what they do, and then start modifying them and play around.
Get your questions from such tinkering answered by reseaching the net etc.
Increase complexity and you'd be on your way in a while.
Search around for an C# Open Source project that interests you. Most projects will take any help you can give. This will allow you to practice your skills in a controlled environment.
You do have means to take courses at the moment. There are entire courses, complete with free textbooks, available online. And that's just one quick example.
I recommend you work your way through a couple of coding and design books while learning the syntax of a language or 2. Code Complete is a great place to start. As far as what you should start programming, aim for simple things that will solve a problem you have. While picking up a language I have done things like write a program that will auto-organize my media library, kick off processes based on things I tweet from my cell phone, quickly add shortcuts to my favorite launcher app, or organize and archive all of my saved school work at the end of a semester. Also, look at a LOT of other people's code. It's can be hard to code better until you've looked at better code.
With this approach you'll build your abstract skills like design and upfront preparation, practical skills like file access and network communication, and general programmer toolbox items like regular expressions and reflection.
Another interesting thing to try is Code Kata. How do you become a great musician or learn to ski or speak a foreign language? Practice. Practice. Practice.
Google for Bruce Eckel's "Thinking in ..." books, they're free and very good
Take a look at functional programming languages - This will broaden your mind and therefore change (and probably enhance) the way you look at code and problems.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
This may sound like a foolish question or an observation, but i have seen that most of the times when one tries to look at the opensource code, there are no comments or just one or two lines at the start of the function telling what the function is used for e.g. register a user or data in table etc. There is no code which actually explains what exactly the function is doing etc.
Is it done intentionally (removal of comments) when a code is released to open source community to make things difficult to understand by others?
There is a line of thought that says that comments are unnecessary when the code speaks for itself. I don't believe comments would be removed on purpose, though.
I've seen both sides, and frankly code in general is insufficiently documented.
I've been congratulated and thanked for leaving copious breadcrumbs but that's because I've had to sift through too much undocumented code to want to subject anyone else to it.
Call it an ethical obligation.
My reason to document code: my short-term memory is junk. I write comments to remind myself of why I did something. Everyone else benefiting from that is gravy.
I don't think there is a practice or policy to remove comments when releasing software as Open Source. A sneaky software publisher might think that a good idea (maintaining de facto exclusivity, because nobody can't understand it, while having released an open source product) but this would cripple the Open Source project from the start and most likely render it unusable.
The code you are talking about is probably just very little documented. As ocdecio says, that can be either a good sign (the code speaks for itself and does not need comments) or a bad one (it is badly documented, bad code). Both cases are entirely possible. :)
What are you comparing it to?
I doubt that closed-source code has better comments.
As for what functions do, there is probably API documentation. No need to duplicate those in comments.
As a rule, functions should be small enough and written in a way that allows working out how it works by just reading them. A comment on top of the function describing what it does helps getting a quick overview of the function itself when reading through the whole source code file (unless the function name speaks for itself).
Many projects are organized in that way, and that is great.
However, what I am often missing when trying find my way around a larger codebase is something describing the big picture, i.e. the general architecture, principles, what goes where and similar things.
All open source is not made the same. This is what we call a generalization.
If you look at the website Ohloh, which tracks a very large amount of the open source software in existence, it paints a much different picture:
http://www.ohloh.net/languages?query=&sort=code
For instance, in the C language, there are 252+ million lines of comments, approx 1 in every 5 lines of C is a comment. For Java, nearly 1 in 3 lines is a comment. That's not bad.
Open source software has bad comments and bad documentation most of the time. There are various reasons why, some better than others. Usually they relate to laziness or the developers 'being in the moment'. None of the reasons are good reasons.