I took typing classes, and they taught that the 6/Y/H/N are typed by the right hand (and 5/T/G/B by the left) as you say, but I have been programming for 16+ years and have gotten into the habit of typing 7/Y/H/B with my right and 6/T/G/V with my left. It just feels more natural. I don't know why they teach it the way that I learned it. Just doesn't make sense to me.
And just for reference, I primarily use Mac computers, and all of their (modern) keyboards have the 6 key significantly closer to the left hand (about 3/4 of an inch "as the crow flies" from the F to the 6 vs the J to the 6).
He meant binary percent:
0b0.00001% of 1 million people = 0b0.0000001 * 1000000 = 1/128 * 1000000 = 7812.5 people
That is much more reasonable, don't you think? The half of a person is probably a French student that can't quite say they "can read French" yet.
Which design flaw in the 18-year-old did they exploit? The one where they're impossible to get out of bed? How does this help them compromise x86 chips?
Knowing how to use a tool most definitely makes it "more useful". Whether it makes it more useful than another tool for the same job is another question.
1 word a (sic) hour is only 24 words a day, whether you leave your computer overnight or not... Did that slashdot post take you more than 2 days to write??
I'm not saying that you shouldn't document it too. Sorry for misleading you. I'm all for documentation of these things too. But people frequently ignore documentation, so having the test case there too helps to prevent broken code from getting into production.
I thought the same thing, but git shows that they were written by the same developer in a single commit. This same developer has caused the developers at my company SO much trouble. He documents the stupid things, and performs useless 'no-op' conversions (another example from Python, str is already a string: str = "%s" % str... not only did is the code confusing [str() anyone?], it's a no-op). On top of that, our code is filled with comments such as "This is a hack" followed by 400 lines of illegible, undocumented code (unless you count "This is a hack" as documentation).
2.8PB? What's the big deal? That's only about 3% of the storage capacity of Lt. Commander Data's 'brain'... And he searches that in only a couple seconds..
Oh, and also, I was basing my comments on previous experience. I have worked using a waterfall model in the past, and in my experience it wasn't usually executed well, or didn't work as well as the team I am a part of now. So no, I don't know the best way to do things, but I do know what has and has not worked for me.
I didn't mean to come across as knocking other approaches. The core of my point was that in my situation, with my team, agile works well. And to address the questions you posed:
Fast - By change of direction, I meant for the REST of the project, not work that was already completed. You can change directions on a weekly basis with agile (if your situation supports it, as someone else suggested, this won't work for the design of an airplane for example).
Cheap - My team tends to use the words priority and value interchangably. The highest priority task is the one that brings the most value to the business as a whole (which can, admittedly, be difficult to judge the "highest" sometimes, but we do our best and people seem happy).
Good - Short development time means we don't have to go back to the research and designing we did 3 months ago to remind ourselves what we're doing. The research and design is done in very small chunks and is usually from the past week. Yeah, some things take more than our one week time to complete, but we have SOMETHING done each week that is measurable, predictable, and best of all, sustainable.
The company I work for employs Agile and Scrum methodologies along with some Extreme Programming mixed in, and I would argue that we achieve all three. I am a part of a team of 6 developers and here is how I believe we achieve all three:
Fast - By only working on the highest priority items, we get the most value out as soon as possible, and are able to switch gears on a weekly basis if the company's direction changes. With a waterfall approach (the most common I think), if the plan changed halfway through, you'd have to scrap everything you've done so far and restart (or risk taking on some serious technical debt).
Cheap - Because we are only completing the highest priority items, we get the most value in the least amount of time. And less time spent means less cost. When we get down to the lower priority items, the product owner can decide on a whim that we don't really need to complete features XYZ, because what we have already completed gives us 90% of the business value for 50% of the cost.
Good - Because our development cycle is so short (1 week), we are always working on things that are fresh in our mind. Also, when we're only focused on one feature at a time, we can really make sure that feature is done right, instead of worrying about how 60 different features are going to fit together (which can lead to some serious over-development and result in more technical debt). Paired programming also helps here, because we have a sort of built in QA as we develop from the person sitting next to us.
The feedback we have received from the company is that we are a marvelous improvement over the previous team, and all six developers have been with the company for less than 2 years. The shared knowledge that is achieved through paired programming has really helped us to excel above the company's expectations. I have some references to some great Agile/Scrum coaches if anyone is interested. Hit me up at Jake{dot}Griffin{at}gmail{dot}com if you're interested.
SPOILER ALERT!! I was thinking the same thing. In the other movies, Professor X met Jean BEFORE he was paralyzed (he walked into her house). But in this movie, he is paralyzed at a much younger age than the age he looked walking into her house.
Do your research. They're still looking onto optics. Copper was just simpler to implement. When they get the optics side done, it's expected to increase the bandwidth of the technology by a factor of 10 (10Gb/s to 100Gb/s)
I was about to post a link to a pic of me trying to plug into a port with the USB logo pointing "up"... ALL of my USB ports are sideways. I rarely see them any other way.
Slashdot Mirror
Nope. It's actually creating MineCraft mods, etc. http://www.gamestartschool.org...
My thoughts exactly upon reading the headline.
I took typing classes, and they taught that the 6/Y/H/N are typed by the right hand (and 5/T/G/B by the left) as you say, but I have been programming for 16+ years and have gotten into the habit of typing 7/Y/H/B with my right and 6/T/G/V with my left. It just feels more natural. I don't know why they teach it the way that I learned it. Just doesn't make sense to me.
And just for reference, I primarily use Mac computers, and all of their (modern) keyboards have the 6 key significantly closer to the left hand (about 3/4 of an inch "as the crow flies" from the F to the 6 vs the J to the 6).
He meant binary percent: 0b0.00001% of 1 million people = 0b0.0000001 * 1000000 = 1/128 * 1000000 = 7812.5 people That is much more reasonable, don't you think? The half of a person is probably a French student that can't quite say they "can read French" yet.
Which design flaw in the 18-year-old did they exploit? The one where they're impossible to get out of bed? How does this help them compromise x86 chips?
The OP already said he is not on Facebook. Thus he doesn't have any friends. Problem solved.
"Have I made mistakes? Sure."
Knowing how to use a tool most definitely makes it "more useful". Whether it makes it more useful than another tool for the same job is another question.
Most importantly, no one is even close to solving no limit -- where you are allowed to vary your bet size. That changes everything.
If we are under the same assumption of unlimited games allowed and unlimited resources, then yes, they have: http://en.wikipedia.org/wiki/M...
1 word a (sic) hour is only 24 words a day, whether you leave your computer overnight or not... Did that slashdot post take you more than 2 days to write??
I'm not saying that you shouldn't document it too. Sorry for misleading you. I'm all for documentation of these things too. But people frequently ignore documentation, so having the test case there too helps to prevent broken code from getting into production.
I thought the same thing, but git shows that they were written by the same developer in a single commit. This same developer has caused the developers at my company SO much trouble. He documents the stupid things, and performs useless 'no-op' conversions (another example from Python, str is already a string: str = "%s" % str... not only did is the code confusing [str() anyone?], it's a no-op). On top of that, our code is filled with comments such as "This is a hack" followed by 400 lines of illegible, undocumented code (unless you count "This is a hack" as documentation).
Or worse, this:
$s = strtolower($s)
$s = "" . $s . ""
"Are you freaking kidding me?! It was ALREADY a string! And PHP does automatic conversions anyway! And those comments are USELESS! WTF?!?!?"
That's why you have TEST CASES for cases x and y; so that if someone ignores the comment, tests will break alerting of an issue!
2.8PB? What's the big deal? That's only about 3% of the storage capacity of Lt. Commander Data's 'brain'... And he searches that in only a couple seconds..
Oh, and also, I was basing my comments on previous experience. I have worked using a waterfall model in the past, and in my experience it wasn't usually executed well, or didn't work as well as the team I am a part of now. So no, I don't know the best way to do things, but I do know what has and has not worked for me.
I didn't mean to come across as knocking other approaches. The core of my point was that in my situation, with my team, agile works well. And to address the questions you posed:
Fast - By change of direction, I meant for the REST of the project, not work that was already completed. You can change directions on a weekly basis with agile (if your situation supports it, as someone else suggested, this won't work for the design of an airplane for example).
Cheap - My team tends to use the words priority and value interchangably. The highest priority task is the one that brings the most value to the business as a whole (which can, admittedly, be difficult to judge the "highest" sometimes, but we do our best and people seem happy).
Good - Short development time means we don't have to go back to the research and designing we did 3 months ago to remind ourselves what we're doing. The research and design is done in very small chunks and is usually from the past week. Yeah, some things take more than our one week time to complete, but we have SOMETHING done each week that is measurable, predictable, and best of all, sustainable.
The company I work for employs Agile and Scrum methodologies along with some Extreme Programming mixed in, and I would argue that we achieve all three. I am a part of a team of 6 developers and here is how I believe we achieve all three:
Fast - By only working on the highest priority items, we get the most value out as soon as possible, and are able to switch gears on a weekly basis if the company's direction changes. With a waterfall approach (the most common I think), if the plan changed halfway through, you'd have to scrap everything you've done so far and restart (or risk taking on some serious technical debt).
Cheap - Because we are only completing the highest priority items, we get the most value in the least amount of time. And less time spent means less cost. When we get down to the lower priority items, the product owner can decide on a whim that we don't really need to complete features XYZ, because what we have already completed gives us 90% of the business value for 50% of the cost.
Good - Because our development cycle is so short (1 week), we are always working on things that are fresh in our mind. Also, when we're only focused on one feature at a time, we can really make sure that feature is done right, instead of worrying about how 60 different features are going to fit together (which can lead to some serious over-development and result in more technical debt). Paired programming also helps here, because we have a sort of built in QA as we develop from the person sitting next to us.
The feedback we have received from the company is that we are a marvelous improvement over the previous team, and all six developers have been with the company for less than 2 years. The shared knowledge that is achieved through paired programming has really helped us to excel above the company's expectations. I have some references to some great Agile/Scrum coaches if anyone is interested. Hit me up at Jake{dot}Griffin{at}gmail{dot}com if you're interested.
SPOILER ALERT!!
I was thinking the same thing. In the other movies, Professor X met Jean BEFORE he was paralyzed (he walked into her house). But in this movie, he is paralyzed at a much younger age than the age he looked walking into her house.
If by "soon" you mean 8-10 months.
Okay, Robert Lawrence. Keep thinking you're safe.
Do your research. They're still looking onto optics. Copper was just simpler to implement. When they get the optics side done, it's expected to increase the bandwidth of the technology by a factor of 10 (10Gb/s to 100Gb/s)
I was about to post a link to a pic of me trying to plug into a port with the USB logo pointing "up"... ALL of my USB ports are sideways. I rarely see them any other way.
The proprietary vs open argument mostly only holds water with (other) nerds.
Yeah, my only scenario is:
Slashdot in one window, things I'm avoiding working on in the other.