Related
I am new to programming and I have some doubts about it. I have read hundreds of time that coding is really mind dependent or it is logic game and critical thinking is a must have skill for it, but somehow I wonder if that is really true. For e.g. I find problems on coding practice sites such as hackerearth interesting and I get pretty sure that it(coding) is a "math oriented logic puzzle" but whenever I see, for example, people asking code for "how to create a progress bar in html", "how to code auto fill otp in android app", "how to ask permission for location in android app" or "how to create circle in pygame(a Python library)", I really think that real world industry solutions are not "logic puzzles" on hackerearth but a copy paste or fairly say, the invented wheel that really gets used again and again. And that's what you require as a skill or are asked to do in industry so where is the "real brainstorming or logic"? I get really confused over this. So is coding really "logic" or "a reusable plastic polythene" that one generation of programmers pass to next and that to next and so forth? I mean somebody at first time really must have used logic in past(in examples that I talked about or like them) or were they really created for the "copy paste chains" or say for standard use? Can they not be designed in different logic?
Note:-
I have used "coding" and "programming" interchangeably here
and really don't want the old discussion here, so please
answer specifically and comprehensively!
Please don't vote it for closing citing it "as too broad" because
superuser is, I think, somewhat "not programming oriented" and it
can be best answered here despite some generality of it.
The puzzle is the part where you get diffrent snippets and change them so you can use them together to create something.
I've tried to get an answer to this question in VB IRC channel, I've looked around stackexchange, stackoverflow, superuser, and elsewhere. Answers come close, but not what I am wanting to know.
This is a curiosity question only, not one of necessity. I just want to know how things work. It has nothing to do with any bug, enhancement request, or security issue. If you feel this forum is not the place to get an answer to this, please refer me to the proper venue. Thanks. (Although it is hard for anyone to imagine that VBox's own forum could be the wrong place, I did not see an answer to my specific question or a place to post to an appropriate category.) Whatever happens, please don't close my question without at least pointing to a better resource (I hate when that happens!). Thanks again.
Now, the question: How does virtualbox's host driver calculate the total number of virtual CPU's to provide?
(Please note I will not respond to answers from people who did not really read the question, or at least first ask for more clarification. I think this is a VERY straight-forward question.)
Let me break the question down so as to be as precise and concise as possible as to what I am really asking. I am curious to know how the VirtualBox HOST software (whatever portion that may be) determines how many VIRTUAL CPUs appear on the configuration interface where the user selects how many VCPUs they would like to apply to a specfiic VM.
What I am NOT asking: I am NOT asking about the miracle of virtualization hardware, etc., in general; I understand multiple cores and multiple threading, VTx, etc. I am NOT asking how many I should use for a specfic VM or application. I am NOT asking for help in configuring any specific VM in my question. I am NOT asking anyone to ask ME why I need to know -- I told you already; I am merely curious. If my specific question does not interest you, that's fine. Again, this is just a simple, straight-forward question: How does VBox arrive at the number?
What I already know: It is true that, at least generally, the answer is 2x as many as physical CPUs; OK, if so, why 2x and not 3x or some other multiplier? (I know fractional amounts won't work for odd-number of cores or threads; I am just being as general as I can be.) For instance, on my Phenom II X6, VirtualBox presents me with up to 12 VCPUs. If the answer is the threads, well, that can't be since my particular Thuban does not have threads (some Thubans do, some don't). What my Thuban DOES have, though, is hypertransport, but not hyperthreading. Likewise, my old Phenom II X2 will allow 4 VCPU's in Virtualbox.
I have already read the numerous responses on the sites mentioned above admonishing users NOT to use more than one VCPU per VM because it adds overhead (for one thing, you must run the IOAPIC, which introduces a performance hit). I've also read posts where the question sounds like mine, but they do not ultimately give an answer to this.
Is the answer some kind of sigma sum or logarithmic formula? Is it complex enough to exceed this forum's formatting capabilities? Hard to imagine why it is so difficult to get an answer to this, which I figure would have been asked and answered many times over. I really want to know why it seems to be 2x usually; why that is the "magic" number. If I read the source code (assuming this is available), will the comments explain why?
I will really appreciate and admire the soul(s) who read and answer this question, and not some other question not being asked. I also hope you will not redirect me to the dark and hostile channels of IRC; there are some very sociopathic entities on IRC whose remarks remind me of some of the unsubs on Criminal Minds. Note that I said "some" -- there are helpful people there also. Not meaning to antagonize; I just hate going to IRC anymore. If you know of a specfic helpful nick on IRC with this, I'd appreciate that also.
BTW, I have been googling for answers to this and other questions and reading SO, SE, and SU boards and I see where some people respond with answers that are totally irrelevant. That's the reason for what may sound like a harsh tone by me. This is my first post, and I hope the response will be more positive than a few of my experiences on IRC.
It seems you are asking "How does the VirtualBox GUI calculate the available range for the Processor(s) slider under the System settings?"
Because VirtualBox is open source (and very clean, well written source) it isn't too hard to dig into the code and research out the answer. Digging down into the /src/VBox/Frontends/VirtualBox/src/settings/machine folder you can see all the UI* files that comprise the settings UI elements. The specific file that will have your answer is UIMachineSettingsSystem.cpp. Starting on about line 45 (as of revision 43459), you can see the following code:
/* Setup constants */
CSystemProperties properties = vboxGlobal().virtualBox().GetSystemProperties();
uint hostCPUs = vboxGlobal().host().GetProcessorCount();
mMinGuestCPU = properties.GetMinGuestCPUCount();
mMaxGuestCPU = RT_MIN (2 * hostCPUs, properties.GetMaxGuestCPUCount());
The mMinGuestCPU variable and associated GetMinGuestCPUCount() method (and mMaxGuestCPU / GetMaxGuestCPUCount()) should be relatively straightforward - typically it will be 1 for the min and the max will be the number of physical/logical cores available on the host.
Thus, to answer your question - the scale for the slider is typically 1 through two times the number of cores available. I would strongly encourage you to download the source code and dig into the methods that calculate those numbers and see for yourself how they are calculated and the nuances that are involved. Specifically the vboxGlobal().host().GetProcessorCount() method.
I was talking to someone in a bar not too long ago, and the inevitable question of "What do you do?" Came up. My response "Oh, I just recently graduated; I work in company X. I'm a programmer" didn't quite satisfy her.
I've had this conversation a hundred times and people are never quite happy with the answer. They always have more questions. I think this is because, for the mostpart, people don't really know what a programmer does. The answer to this question normally gives you an insight into a person (sort of): Accountants might be analytical and good with numbers, lawyers might be good with words and debate etc. 'programmer' doesn't.
so I tried to give an answer that would give that sort of insight.
I tried to illustrate my point of "Well It's basically fancy problem solving" with an example of a classic programming problem.
The first thing that jumped into my head (for some reason) was the smallest subset problem... but I'd have to explain arrays, time complexity, etc
I thought of n-queens problem, but she'd never seen a chessboard in her life (yeah, I know)
Towers of hanoi was too hard to envision in general...
So I Was stuck and the topic changed.
Can you guys think of an example of a problem; that a complete lay(wo)man can understand, which would give someone an idea of the kind of thinking programmers have to do? (and by extension save me answering awkward questions about how I make my living)
I get asked what I do too, and basically, all I say is that You wouldn't understand much about it, which will get you one of two responses: "Try me" and shes interested ->move to next section of comment, or she will just shut down and think that you think she's not intelligent. USE WITH DISCRETION.
Now, if she says try me, you have a challenge. Obviously what you do is going to be over her head, but you know you can explain a little to her. Basically, what I try to explain is that I am a logician, kinda like a magician. When the computer needs to be told to do something, and no one else knows how to tell it, they call me up. Sometimes it's simple, other times, its likes climbing Mt. Everest with your fingers on some impossibly difficult task. Imagine the worlds largest word search, and you don't know what words you're looking for. That's what I do. I find those words. So as you could imagine, I'm quick to notice little things and remember them. ;)
That should elicit the kind of response out of any women worth your time.
Good Luck!
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 3 years ago.
Improve this question
Our profession often requires deep learning; sitting down and reading, and understanding. I'm currently undergoing an exam period, and I'm looking for ways to learn more effectively.
I'm not asking about what to learn, or whether to prefer blogs over books, etc. My question is much more physical than that -
What do you do when need to study, and I mean study hard?
I'm looking for answers such as
I slice my time to 2.5 hours intervals and make a break between them, but never during.
I keep a jar of water nearby.
I wake up at 6 o'clock sharp and start my day with a session at the gym.
What good learning habits did acquire, or wish you had acquired?
(I know this isn't strictly programming related, but it is programmers related)
I find the best way to set yourself up for learning is:
Get plenty of exercise and rest
Eat a balanced diet with little sugar and caffeine
Try to find a quiet area conducive to concentration
Try to practice what you learn from a book - theory is ok, but practice embeds the knowledge.
"The best way to test whether or not you know something is to try to explain it to someone else from scratch."
That has to be one of the best ideas I was ever given about knowing whether or not I really know something.
Make sure it's quiet and comfortable around you.
enough to drink and eat
don't just read but take notes, draw mindmaps and the like
don't just read but try
make a report, blog entry, presentation out of what you learned
learn the same thing from different sources: Don't just believe what person A has to say look for, read and understand the opinion of person B and C as well and understand the differences.
take nothing for granted
apply the knowledge to an actual project
I set aside time every day or x times per week. Otherwise I never do it.
I try to have a diff location every once and awhile (home / coffee shop / stay late at the office) keeps the tedium away.
I am careful about the music I use, try to make sure it is relaxing
Sometimes I leave headphones on even if music is off that way people don't talk to me.
I give myself specific goals before each break or for every session.
I reward myself
Read Andy Hunt's "Pragmatic Thinking and Learning" - lots of good suggestions there.
Tony Buzan wrote The Mind Map Book, describing his ideas for note taking. He also has some process ideas that I found very helpful. Foremost was this one: study new material for an hour, then take a short break (5-10 minutes) and then review the new material. Review the new material again an hour later, then two hours after that, then the next day. You need to refresh your exposure to the material multiple times over the course of time to really take it in.
While reading, I make sure I fully comprehend each section in the text before I continue.
Set up a time and take away all distractions. At home/dorm can be rough, so I would use the library while in college. Getting started is usually the hardest part, so don't set a specific time limit for when to quit. It is distracting, and you will be looking at your clock to see "how much longer you have." You don't want to be in that mindset. Work until you feel your brain is starting to lose focus, whether that is lack of comprehension or having to reread simple paragraphs repeatedly. Take a minute or two as a break, then refocus your mind. When that stops working, it is time for a real break.
Are you a night owl or early bird? Each person is different. I am very productive early in the morning, while my wife can barely function. We all have differences, so don't try to fight your nature.
+1 to what everyone else said. Making cheat sheet/notes were a very important part of my studying habits, whether I could use them on the exam or not.
I find it best to be fully dedicated to the task before I start. If you go into something with low morale, you will not do well. If you go into a task with high morale, you will understand things quicker, be able to apply it to real situations better, and will have a deeper comprehension. If I am not fully dedicated, I don't even bother. I've got better things to do with my time then half ass something, and you probably do too.
Expanding on a comment I left, see this article from Electronic Design from a few years ago: http://electronicdesign.com/Articles/Index.cfm?AD=1&ArticleID=5859.
If you can teach what you learned, you know it.
by Louis Frenzel
All learning is self-learning. Professors, trainers, and all teachers just organize and present the material to be learned. They don't teach it to you. You learn it. You're the one who actually absorbs, understands, and assimilates the knowledge by listening to the lectures, reading, thinking, solving problems, and other activities. Self-learning is a natural, human quality. While most of you have used this method in the past, you may want to do it on a more formal basis to speed up and fine-tune your methods. Here's a suggested approach (and trust me on this, you must write it down):
Clearly identify what you want to learn. Write it out.
Write some learning objectives for yourself. These statements clearly identify what you want to know and be able to do. For example, you should write something like "When I complete this learning assignment, I will be able to design and program an FIR DSP filter." The objectives should be expressed in "behavioral" terms, that is, using words that state some measurable outcome.
Identify some initial resources. Start with books at the local bookstore or go to www.Amazon.com or Barnes & Noble at www.barnesandnoble.com. Most cities don't have good technical bookstores, and it's tough to find anything at regular bookstores. Consider yourself lucky if you have a good technical bookstore or a good college bookstore. Plan to get multiple books to give you greater breadth of coverage with multiple explanations, examples, and perspectives. Don't forget to look through your stack of magazine back issues.
Check out online sources. Do one or more Web searches, or go to relevant company Web sites. You may run across an appropriate tutorial, white paper, or application note that will give you what you need. The large semiconductor and equipment manufacturers have tons of stuff on their Web sites, so start digging. Also check out the professional societies and other sources listed in the tables and sidebars.
Watch out for any conferences or seminars on this topic. Usually, such events never occur when you need them, but you might get lucky. If you find one, attend because it will provide a big head start for your own learning.
Organize your materials. Lay them out, mark them up, and then make an outline based on your objectives. See what you have and what you lack, and make an initial list of things to do.
Dig in. Set aside an hour a day or whatever you can to go through the materials. Turn off the radio, CD player, and television. Make a habit of finding some quiet time to read and learn.
Look for a human tutor. You could be working just down the hall from an expert on the very subject you're trying to learn. Pick his or her brain. Ask this person if he/she will help you understand and learn. Take this person to lunch or offer to pay for lessons. Most people will gladly share what they know, if you aren't too proud to ask. The best way to do this is to learn as much as you can on your own. Then, go for the professional, personal help with tough questions or when you get stuck.
Include some hands-on. Is there any hardware you can buy or put together to help you learn it? Maybe there's some software that will help. Buy it or have your employer buy it.
Write a paper or article or teach what you have learned. You have to know it to write it or teach it. There's no better way to learn for yourself than to have to explain it to others.
I generally find it useful to build a "cheat sheet" or other form of summary as I go.
On one hand, it forces me to reinterpret information and figure out what's really important.
On the other hand, I'm building a useful study tool for last-minute revisions, or future refreshing of knowledge.
2.5 hours without breaks seems like a lot. Experiment with different time slots to see what works best (personally, a sequence of 3x(20 work - 5 break) works well)
Pomodoro Technique for time management
http://pomodorotechnique.com/get-started/
(watch "how" tab)
And the code(for programmers)
while(day) {
for (int i = 0; i < 4; i++) {
work(25);
relax(i < 3 ? 5 : 15);
}
}
You should implement methods
void work(int minutes);
void relax(int minutes);
Variable day changes from other threads
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 10 years ago.
Improve this question
You and I want to be the expert on computer programming or website design, but sometimes a customer would rather try their hand at your specialty than concentrate on real estate sales, marketing, or being a former member of the Israeli army. Then we have a choice: either figure out how to tell the prickly customer their logo would NOT be better spinning in 3-d with a righteous lens flare, or perhaps suffer the small indignity of making link texts as verbose as possible in direct opposition to any style guide ever written.
Have you been able to convince your customers to focus on whatever it is they are trained to do so they will let you execute your technical skill to the best of your ability?
I always try to point my clients in the right direction with regard to design. Sometimes it's just not possible though; they want something that's dreadful design, but they're convinced it's essential to their system. If they're unconvinced after a modest pitch, I just do what they want. They are, after all, the ones paying me (usually) thousands of dollars to build to their spec.
Often the reason the client wants to get involved is they are concerned consciously or unconsciously you don't understand the details of their business or how they do it.
The best approach is to work with the client to learn their business. This involves zero assumptions and learning the "how they do it" of their business. From that, discover all the data they use, what states the data sits in at what point in their process.
Keep taking it back to them and eventually they will realize that not only do you understand their stuff, what they want, and what direction they want to go in, but that you might even know the implications or impacts better than them.
After this they will usually stay out of your hair. This can be hard though when working with micromanaging types, or engineers. By nature they want to know how everythign works which is great. The timing of when it's best to learn how it works is the tough part.
Often you can get stuck in more conversing about solving a problem than it would take to just fix it. Maybe you can tell us more about the client's personality.
The trick is to get them to make the right decisions, but think it's their idea. :-)
You can't have this conversation with them easily in the abstract, but you can drill down and guide them towards the side of righteousness on each individual decision. Eventually, after you've been through this a few times, they'll start to trust you.
If possible, it helps to wait a day. Tomorrow they may be less clear on exactly what they asked for. (Do they really have their heart set on a flaming logo, or was it just a whim?) Then, in your response, you: describe what you recommend, and why. Restate agreed-upon objectives, and show how the solution meets the objectives. And make it sound like it was their idea. ("The point you made yesterday about xxx is really excellent, and I think that suggests a yyy solution.")
At this point you have a choice. You can ideally pretend you never heard their silly suggestion. Or if you feel you have to, respond to it tactfully and explain costs. ("I'm a bit concerned about the animated logo idea, because it may not convey the brand image the way you requested. Of course if you want to go this route, we certainly can--in which case I'd suggest we get our graphic design consultant involved. Let me know if you want to explore this further and get a quote from the consultant for his services.")
I found that customers are always easier to convince by "optical evidence" than by theoretical arguments - so you could e.g. show them logos or the general style used on websites which won a price for their usability, or maybe even show them how some big competitor is doing it, and then point out the benefits based on what they see.
I've also once managed to get rid of a really terrible user interface suggestion by making screen mock-ups of how this feature would actually look and work - and I made sure to make thes mock-up as unappealing as possible ;-) When I presented them, the client quickly realized that there were better ways of achieving his goal.
Knowledge is power. When you know a client is doing something wrong, have the facts ready as to why and present them quickly and in plain english. You need to remind them why they hired you in the first place.
Bearing that in mind, sometimes clients insist on shooting themselves in the foot. Have backups ready, use version control, but most of all: don't antagonize them. Your reputation is worth a lot more than their 3d-logo-spinny site.
Very carefully.
You've got several conflicting issues here: you want to keep the relationship (and the revenue), you want to do good work, and you don't want to end up with your name on a turkey.
Start by asking lots of questions about the business aspect: what do you want it to do, who do you want to reach, what impression do you want to give. Sometimes that will let you turn the discussion to more useful topics.
If that doesn't work, sometimes it helps to mock up the customer's idea and your idea, and compare them; if yours is clearly superior, they may see it.
If not, sometimes you have to remember that contracting/consulting is a form of prostitution; you do what the customer wants, whether it's your favorite thing or not.
The other thing to remember is a lesson I got from another consultant years ago: some customers aren't worth the trouble. he recommended that once you have enough business to live, you make a practice of firing your least liked 10 percent of the customers. Over time you develop a customer base that you can work with, and give the turkeys to someone else.
The problem with customers is that they are the customer. They have hired you to do a project to their specifications. What they seem to have missed in your example is that they have hired you because of your experience. You need to remind them of that fact in a gentle way. Perhaps a story such as "At one client, we used a logo like that and they expereinced a drop in traffic. Once we switched to a flat icon the traffic returned." Doesn't have to be true, per se, but you need to sell it.
All you can do it explain to your customer that they hired you for your expertise in design, but at the end of the day, the customer is always right.
If you find you don't enjoy working for customers like that, simply state at the beginning of a new project that you require complete creative control. If they still want rotating logos, then you'll have to put up with it for that project but at least you can decline any offers from the same customer in the future.