Now add to this that most major contributions in any scientific field occur before someone hits their mid 20's...
Tell me, does this account for the fact that the majority of people working in a scientific field graduate with a PhD in their mid 20s, or is it simply a reflection of that?
I expect that it's a little bit of both. Look however at Kepler and Tycho Brahe. Brahe's observational contributions aided Kepler, but he started well before he was 30. Kepler had his theories before 30, and was aided by Brahe into his 30's proving them out. Counter examples include Newton, and so on. Most Large contributions that aren't ideas themselves are contributions based on the wealth of the contributor, e.g. The Allen Telescope Array.
Like the GP, I'm in my late 30s and have found that my current field is less than optimal. It is a) unfulfilling, b) extremely underpaid (if I do more than 13 hours a week, the CEO running the studio is just as likely to steal my hours from me as not), and c) unlikely to go anywhere.
Reason (a) is motivation to do something that could be big, if the new reason is passion. Reason (b) is a piss poor reason to do something big; there's no passion involved. Reason (c) is ennui.
If you get into something solely to satisfy (a), you have a chance at greatness; if you do it for the other two reasons, even in part, you are unlikely to have the fire to spark the necessary effort. For example, the OP's willingness to dedicate 10 hours a week from a 24x7 = 168 total hours in a week really speaks to the idea of someone acting out a dilettante reason, rather than a reason of passion. Excluding sleeping, you could probably argue for 86 hours a week for a passion, and that's less than 11% of the "every moment of every day" you'd expect with a passion.
Since you already have a full life, something would have to give. The amount of time you estimate to be available would get to hobby level: the same as the other thousands of amateur astronomers in the country. But it's not enough to do any serious studying, get qualified or do research to a publishable quality.
This.
I read through the comments to find this comment so that I didn't just post a duplicate if someone else had covered the ground.
Let me be really blunt about the amount of time you are intending to invest in this project. If you were taking a college course, you should expect to spend 2 hours out of class for each hour you spend in class, and given that you only have 10 hours to dedicate to the idea, that's effectively 3 credit hours for every interval. So if you picked a community college, and they offered all the classes you needed, you should expect to have your Bachelor's of Science in any given degree field in about 23 years. That gets you to the necessary 210 credit hours for an Astronomy degree.
Let's say, though that you are a super genius, and can do 1:1 instead of 1:2 for in/out of class. That only cuts your time by 1/3, which means that you get that degree in 15 years instead.
Now add to this that most major contributions in any scientific field occur before someone hits their mid 20's; there are exceptions, but let's say again that you are exceptional. What contributions do you expect to be able to make after age 61 / 53, with your shiny new Bachelor's, since you're unlikely to find someone to hire you at that age, and you're unlikely to be able to afford instrument time on the necessary equipment on your own?
Apple initially didn't open up the iPhone to Apps at all because Steve was deathly afraid of building another Newton.
Then they wanted to open them up, but there was not rational set of APIs, there was just an internal morass, because it had never been designed with the idea of hardening one app on the iPhone from interference by another app on the phone, or hardening the phones functions against a malicious app.
This is a single App on a single use, incomplete, API, one which was built only to host this App and nothing else. Could that API be exposed, and used for other applications? Yeah. Would that enable all possible NFC applications which you might want to implement in the future? Not a chance in hell.
This is just Apple wanting some bake time so that they can rationally support an API that they happily demonstrated opening hotel doors and other things which they are not prepared to open up at this point in time.
Tests need to be fast and repeatable (among other characteristics). Tests must be of high quality as your production code. If you would fix "timing related" issues in your production code, there is no reason your tests suffer from the "timing related" issues either.
There's no reason they *should*, but they do unless you correct the test. The problem is in the test code, or in the wrapper that runs the test code. But consider an automated login test on an isolated network with a credentials server that races to come up with the browser that's attempting the login in the test case. If the login happens to start before the login server gets up and stable, then your login fails, and so does your test case, even though it's not a problem with the browser you are nominally testing.
This is/was a pretty common failure case with the ChomeOS build waterfall because Chrome was considered an "upstream" product, and therefore changes in Chrome, when they occurred, could throw off the timing. There wasn't a specific, separate effort to ensure that the test environment was free from timing issues. And since you can't let any test run forever, if you intend to get a result that you can act upon it in an automated way, you get transient failures.
Transient test failures can (sort of) be addressed by repeating failed tests; by the time you attempt to reproduce, the cache is likely warmed up anyway, and the transient failure goes away. Problem solved. Sort of. But what if everyone starts taking that tack? Then you end up with 5 or 6 transient failures, and any one of them is enough to shoot you in the foot on any given retry.
Now add that these are reactive tests: they're intended to avoid the recurrence of a bug which has occurred previously, but is probabilistically unlikely to occur again; when do you retire one of these tests? Do you retire one of these tests?
Consider that you remove a feature, a login methodology, a special URL, or some other facility that used to be there; what do you do with the tests which used to test that code? If you remove them, then your data values are no longer directly comparable with historical data; if you don't remove them, then your test fails. What about the opposite case: what are the historical values, necessarily synthetic, for a new feature? What about for a new feature where the test is not quite correct, or where the test is correct, but the feature is not yet fully stable, or not yet implemented, but instead merely stubbed out?
You see, I think, the problem.
And while in theory your build sheriff or other person, who's under fire to reopen the tree, rather than actually root-causing the problem, doesn't have time to actually determine a root cause. At that point, you're back to fear driven development, because for every half hour you keep the tree closed, you have 120 engineers unable to commit new code that's nor related to fixing the build failure. Conservatively estimate their salary at $120K/year, then their TCO for computers and everything else is probably $240K/year, and for every half hour you don't open the tree back up, that's ~$14K of lost productivity, and then once you open it up, there's another half hour for the next build to be ready, so even if you react immediately, you're costing the company at least $25K one of those bugs pops on you and you don't just say "screw it" and open the tree back up. Have that happen 3X a day on average, and that's $75K lost money per day, so let's call it $19.5M a year in lost productivity.
This very quickly leads to a "We Fear Change" mentality for anyone making commits. At the very least, it leads to a "We Fear Large Change" mentality which won't stop forward progress, but will insure that all forward progress is incremental and evolutionary. The problem then becomes that you never make anything revolutionary because sometimes there's no drunkard's walk from where you are to the new, innovative place you want to get to (eventually). So you don't g
Having some experience with both FDD and TDD, I can attest that test driven culture where automated testing is fully integrated into the dev process pretty much addresses all three of your conditions.
The wrong kind of TDD leads to FDD of the type where you're afraid to break the build.
The problem with TDD that leads to this is that TDD is almost totally reactive; that is, you find a bug, you write a test for the bug so you can tell when it's gone; you get rid of the bug, and now you have this test which is going to be run on each build, as if you are not already hyperaware, having both experienced and fixed the bug, of the conditions leading up to the bug. The annoying part, of course, is when you start taking longer and longer amounts of time to get through the build to an acceptance of the build, for each test you add. Then to make things even worse, add to that the occasional false failure because the test is flakey, but it's someone's baby and it "usually works" and the failure is "timing related", and now you're testing the test, and rejecting a perfectly good build because you're unwilling to either rip out the test completely, or make it non-fatal and assign the bug on it back to the person who wrote the original test.
TDD with test cases written up front, and not added to without an associated specification change: Good.
TDD with test cases written to cover historical bugs identified through ad hoc testing: Project Cancer.
The second worst thing you can possibly do is write tests for no good reason because you're able to write tests, but unable to contribute to the core code, and you still want to contribute somehow. The worst thing is being the code reviewer and letting that type of mess into your source tree because you want the person submitting the tests to not feel bad about them not getting accepted.
Or just the better alternative. It is hard to seriously argue that Boeing is so much behind Elon Musk, that anything space related should be given to the latter.
Given that Boeing will already be 3 years late to the party, when SpaceX has manned capability up and running this coming January? We're supposed to wait another couple of years for manned launch capability, when the Russians have already said they wouldn't be hailing our asses into orbit any more? I don't think "Time To Market" is a difficult argument.
One thing Swift will address... There are currently 3 memory management models in use in Objective-C, and for some of those models, you don't get a retain count automatically (for example, this is the case for a number of collection objects when doing an insertion).
Swift has the opportunity to rationalize this, which is not something you could do with the Objective-C libraries themselves, since doing so would change historical APIs and thus break old code.
It wasn't really until Metrowerks basically became incompatible with the Intel switchover and the 64 bit support had to drop certain types of support from Finder due to 64 bit inode numbers, and while I happily would have made them new header files so that they would have continued to work with the UNIX Conformance work, where Ed Moy and I basically broke their local private copies of their header files, since Motorola sold off the Intel version of the Metrowerks C the week because Apple announced Intel, it was pretty much DOA at that point.
So it basically took an Act Of God to get some people to get the hell off some of the old APIs we had been dooming and glooming about for half a decade.
Swift is another opportunity for that type of intentional non-exposure obsolescence to clean up the crappy parts of the APIs and language bindings that haven't been cleaned up previously due to people hanging onto them with their cold, dead hands. Hopefully, they will advantage themselves of this opportunity.
You cannot base any real analysis on figures take by looking at an artists rendering of the site.
Wait. Those weren't artists renderings of actual flying car prototypes on the cover of the Popular Science Magazine covers back in the middle of last century?
"Information to enable a fast electronic contact and direct communication with them, including electronic mail address."
You can hardly more clear than that. And if Google answers:
Google will not respond to or even read your message
it definitely breaks the law, since this is not even a one sided communication.
The problem here is that the law *requires* an email address. It was never really thought out for large companies with billions of customers, and the law is effectively a bad law as a result, but it is still in fact the law.
I can imagine that the response is going to be something like an IVR system, where you are emailed back something which requires you provide more context ("or you can click here"), and repeats the process narrowing down the context, each time ("or you can go here"), until it drills down to the automated system where it can bucket it into the appropriate web form you should have used in the first place instead of sending them an email, or your problem is answered, or you give up and go away.
Unless there's also a law against IVR in Germany?
Guaranteed that most of these emails to that address are SPAM and/or people bitching about seeing things in the search results they don't want to, or not seeing things in the search results that they expected to, and a human would be telling them, very politely, that nothing will be done about their complaint and/or they are not interested in pretending to be the heir to the fortune on deposit in the Bank of Lagos by the wife of the late oil minister ("now deceased, God Bless").
The fiction of net metering is that you will not be paid the same amount for the electricity you generate as for the electricity you consume.
On of the purposes of "Smart Meters" is to permit differential pricing on electricity produced vs. consumed; it's not just to provide a temporal demand market. There are already tariffs in place in California where PG&E only has to buy as much electricity as you consume for a net 0 energy usage, rather than being required to purchase everything you generate over what you consume.
The idea of a large grid only works if someone pays to maintain that grid, and that pricing comes in as a differential.
Everyone can't do what Tesla is doing because not everyone is going to have the storage capacity to make it economical; Tesla can just rota the batteries it manufactures in service to the manufacturing plant itself, as part of "burn in testing", so that it'll get local off-grid storage as a side effect of the manufacturing process itself.
I suppose that "every rechargeable battery manufacturer can do what Tesla does" would be a fair statement, but that's a tiny subset of "everyone"
Almost everything everyone complains about regarding Facebook is related to its choice of NoSQL as an underlying implementation technology:
- You don't get to see all of your friends posts - Everyone who follows you isn't guaranteed to see all of your posts - The computational overhead of making ACID guarantees is available... if you pay for the extra work (i.e. step back to ACID) - Posts show up out of order - A comment on an old post by someone brings the whole thing back as if it's a new post
It follows that the other things that people complain about Facebook over are sure to follow into the NHS implementation, if they are taking that lead to its logical conclusion - meaning advertising replacing desirable content in the medical record.
Great, they've invented "MedBook"... what you see when you look at it is a fraction of the available data at any one time because it has "arrived" at the node where you are viewing it from yet.
What do I have to do so that my drug allergies and blood type are "sponsored postings" so that when my doctor looks at them, he doesn't kill me due to all of the auto-play video advertisements for Cialis being there instead of the information I want to be there?
Museum specimens were commonly preserved with formaldehyde, which damages DNA.
The technique in question would use the DNA from a *lot* of cells. Even if all of them were damaged, they would not be damaged in precisely the same way, which is why the technique works: it's a statistical technique. Give 1500 full specimens with multiple sets of damage, they should, on average, get the full genome for the species, since that's a viable number of individuals to propagate the species.
So again, unless something knocked out a specific chromosome in *all* the cells of *all* the specimens, there's nothing in particular, I'm not seeing the problem here that's being solved by inserting non-species DNA into the genome, since it should be acomplete species genome.it's going to be present in the majority of the samples anyway, and weeding out the damage is a computational bioinformatics task, not a "Well, it's not in this one cell; we're screwed" task.
I'm not understanding "missing DNA"... if they think there is "missing DNA",and they have 1,500 specimens, all less than 2-300 years old, they need to talk to J. Craig Venter, because they're doing it wrong.
This is surprising, coming as it does on the heels of Microsoft's refusal to comply with the U.S. Federal court order to hand over overseas held emails.
So I will spell out some of the political consequences here.
The service closure forces a service switch on the remaining people who were using non-Microsoft MSN clients and thus avoiding the Guangming, which operates the Chinese version of Skype, which has been modified "to support Internet regulations", which is to say The Great Firewall of China. If these users want comparable services, the only comparable one now available to them is Tencent’s QQ messaging software, which from the start has been designed "to support Internet regulations". So there are no longer any "too big to shoot in the head" options which do NOT "support Internet regulations".
So really the only people who care about this will be Chinese dissidents who want to communicate with each other using an encrypted channel through a server inaccessible to the Chinese government, and any journalists seeking an encrypted channel whereby they can move information out of China without having to have a government approved satellite uplink handy, or a willingness to smuggle out data storage some other way.
The linked article makes it pretty clear they were basing it on Samsung Exynos SoCs - who *cares* whether or not Broadcom would source them parts, if they weren't even using Broadcom in their design?!? This is like using a Motorola 6502 in a design, and then claiming that Intel wouldn't sell you 8008's... what the hell?
No, no, no! You have it backwards. Here on Soviet Slashdot, developmental plasticity fish overlords welcome you!
Ironically, it's a revival of Lysenkoism, which has its supportive roots in Soviet era propaganda - making your comment quite apt, given that there was official party support from Stalin, to the point of those opposing the idea being executed. It's gained popularity again due to possible epigenetic mechanisms, but this hasn't really panned out in terms of direct heritability of the induced characteristics.
We're too cheap to hire a less experienced person and train them to do their job properly.
Get your own training. If I have to train you to do your job properly, I damn well don't want you.
If I wanted to run a training program, I'd open my own version of DeVry University or University of Phoenix. I am in business to do what my business does, and as we are not a vocational education institution, get your freaking vocational education somewhere else.
Companies are not interested in making over someone who isn't a good employee into one. It's the same reason you don't buy burnt out light bulbs, and remanufacture them into working light bulbs yourself, when there are perfectly good light bulbs sitting on the next shelf.
The idea that companies should provide vocational training to potential employees because the educational system has failed to provide them with the ability to be an asset to a potential employer is wrong headed. It is not the responsibility of the employer to make a person employable, it is the responsibility of the person to make themselves employable.
IF we were talking about blue collar manufacturing jobs, or sales/cashier/hamburger jobs, then yeah, apprenticeships and on the job training make sense; in technical areas, it doesn't make sense, any more than it would ti hire someone at a hospital, and on-the-job train them until they were a doctor.
As you surely know, coal plants exhaust is filtered to the extend that the exhaust is cleaner than the intake. At least that is so in germany
Accepting your premise...
It sounds like the Germans need to set up some big filter plants that do nothing but intake, filter, and exhaust the air, if their air is so shitty that running it through a coal fired power plant cleans it.
Bob Wallace was one of the originators of the concept of "shareware", and he got paid not for his software. This made people wonder how Quicksoft was able to stay in business.
When questioned about this at one convention, he made circling motions with his hands on either side of his head, and said "Software is... all up here... it's not real, it's ephemeral. I don't sell software, I sell manuals". So Quicksoft made its money, and its livelihood in the margin between the cost of mass-producing a manual vs. printing it out from a floppy disk and using up a bunch of tractor feed paper and expensive ribbon.
Or, to put it another way, Quicksoft made their money by having a relatively feature-full product which was nearly impossible to use without documentation. And people have been mistakenly trying to copy his success by utilizing the same technique, ever since.
Why did WordPerfect lose out to Microsoft Word? It wasn't because WordPerfect didn't already own the market; it did. It wasn't because Microsoft Word had more features; it didn't. Was Word a lot better, intrinsically, than WordPerfect? It actually wasn't.
Frankly, it was because of the F1 key. By the time WordPerfect got around to deciding they needed a "Help!" key, some of the function keys were already assigned, and so they assigned the next available one to be the "Help!" key. It helped sell a hell of a lot of keyboard templates. And it hid the help from anyone who'd experimentally go looking for it by hitting unlabeled keys in order until they found it (in fact, this would totally screw you up in WordPerfect).
Microsoft hit on a UX innovation: when something goes wrong, make the "Help!" key the first key someone is likely to hit, before all other keys.
And then they did it one better: The F1 was assigned to be the "Help!" key in *all* their products. Instead of just being a great UX thing, locating the key where they did on the basis of probability, they turned it into a Schelling Point: anyone who wanted "Help!" in any Microsoft product knew where to go to find it, if they had ever used some other Microsoft product, and needed "Help!" there.
So back to the original question: should you invest in documentation? Well, yes... if your product has already failed to the point where it's nearly impossible to use without documentation, or because, like Bob Wallace, you intentionally made it nearly impossible to use without documentation because that's one of the premises of your business model.
Maybe you want to write books on your project, once it's used by enough people to make that profitable, and that's how you plan to turn your hobby into a vacation fund. Or maybe you want to get to be a published author about a product so you get hired as a tech writer somewhere, or you get a lot of speaking engagements, and monetize your efforts that way. But if making your product hard to use was one of your initial conditions, then I think your software is broken.
It is more cute that you don't kniw the difference between waste and spend fuel. Reprocessing spend fuel produces more waste than not reprocessing, hint: for fuck sake read about the topic instead of making cute comments that in hint seight only show you are a dump ass, and not a smart ass.
It's also cute when someone who can't spell attempts to "correct" a theoretical physicist on a physics topic, and their correction is wrong:
Slashdot Mirror
Tell me, does this account for the fact that the majority of people working in a scientific field graduate with a PhD in their mid 20s, or is it simply a reflection of that?
I expect that it's a little bit of both. Look however at Kepler and Tycho Brahe. Brahe's observational contributions aided Kepler, but he started well before he was 30. Kepler had his theories before 30, and was aided by Brahe into his 30's proving them out. Counter examples include Newton, and so on. Most Large contributions that aren't ideas themselves are contributions based on the wealth of the contributor, e.g. The Allen Telescope Array.
Like the GP, I'm in my late 30s and have found that my current field is less than optimal. It is a) unfulfilling, b) extremely underpaid (if I do more than 13 hours a week, the CEO running the studio is just as likely to steal my hours from me as not), and c) unlikely to go anywhere.
Reason (a) is motivation to do something that could be big, if the new reason is passion.
Reason (b) is a piss poor reason to do something big; there's no passion involved.
Reason (c) is ennui.
If you get into something solely to satisfy (a), you have a chance at greatness; if you do it for the other two reasons, even in part, you are unlikely to have the fire to spark the necessary effort. For example, the OP's willingness to dedicate 10 hours a week from a 24x7 = 168 total hours in a week really speaks to the idea of someone acting out a dilettante reason, rather than a reason of passion. Excluding sleeping, you could probably argue for 86 hours a week for a passion, and that's less than 11% of the "every moment of every day" you'd expect with a passion.
I can only spend maybe 10 hours a week on this
Since you already have a full life, something would have to give. The amount of time you estimate to be available would get to hobby level: the same as the other thousands of amateur astronomers in the country. But it's not enough to do any serious studying, get qualified or do research to a publishable quality.
This.
I read through the comments to find this comment so that I didn't just post a duplicate if someone else had covered the ground.
Let me be really blunt about the amount of time you are intending to invest in this project. If you were taking a college course, you should expect to spend 2 hours out of class for each hour you spend in class, and given that you only have 10 hours to dedicate to the idea, that's effectively 3 credit hours for every interval. So if you picked a community college, and they offered all the classes you needed, you should expect to have your Bachelor's of Science in any given degree field in about 23 years. That gets you to the necessary 210 credit hours for an Astronomy degree.
Let's say, though that you are a super genius, and can do 1:1 instead of 1:2 for in/out of class. That only cuts your time by 1/3, which means that you get that degree in 15 years instead.
Now add to this that most major contributions in any scientific field occur before someone hits their mid 20's; there are exceptions, but let's say again that you are exceptional. What contributions do you expect to be able to make after age 61 / 53, with your shiny new Bachelor's, since you're unlikely to find someone to hire you at that age, and you're unlikely to be able to afford instrument time on the necessary equipment on your own?
I would say you have it right.
Apple initially didn't open up the iPhone to Apps at all because Steve was deathly afraid of building another Newton.
Then they wanted to open them up, but there was not rational set of APIs, there was just an internal morass, because it had never been designed with the idea of hardening one app on the iPhone from interference by another app on the phone, or hardening the phones functions against a malicious app.
This is a single App on a single use, incomplete, API, one which was built only to host this App and nothing else. Could that API be exposed, and used for other applications? Yeah. Would that enable all possible NFC applications which you might want to implement in the future? Not a chance in hell.
This is just Apple wanting some bake time so that they can rationally support an API that they happily demonstrated opening hotel doors and other things which they are not prepared to open up at this point in time.
Tests need to be fast and repeatable (among other characteristics). Tests must be of high quality as your production code. If you would fix "timing related" issues in your production code, there is no reason your tests suffer from the "timing related" issues either.
There's no reason they *should*, but they do unless you correct the test. The problem is in the test code, or in the wrapper that runs the test code. But consider an automated login test on an isolated network with a credentials server that races to come up with the browser that's attempting the login in the test case. If the login happens to start before the login server gets up and stable, then your login fails, and so does your test case, even though it's not a problem with the browser you are nominally testing.
This is/was a pretty common failure case with the ChomeOS build waterfall because Chrome was considered an "upstream" product, and therefore changes in Chrome, when they occurred, could throw off the timing. There wasn't a specific, separate effort to ensure that the test environment was free from timing issues. And since you can't let any test run forever, if you intend to get a result that you can act upon it in an automated way, you get transient failures.
Transient test failures can (sort of) be addressed by repeating failed tests; by the time you attempt to reproduce, the cache is likely warmed up anyway, and the transient failure goes away. Problem solved. Sort of. But what if everyone starts taking that tack? Then you end up with 5 or 6 transient failures, and any one of them is enough to shoot you in the foot on any given retry.
Now add that these are reactive tests: they're intended to avoid the recurrence of a bug which has occurred previously, but is probabilistically unlikely to occur again; when do you retire one of these tests? Do you retire one of these tests?
Consider that you remove a feature, a login methodology, a special URL, or some other facility that used to be there; what do you do with the tests which used to test that code? If you remove them, then your data values are no longer directly comparable with historical data; if you don't remove them, then your test fails. What about the opposite case: what are the historical values, necessarily synthetic, for a new feature? What about for a new feature where the test is not quite correct, or where the test is correct, but the feature is not yet fully stable, or not yet implemented, but instead merely stubbed out?
You see, I think, the problem.
And while in theory your build sheriff or other person, who's under fire to reopen the tree, rather than actually root-causing the problem, doesn't have time to actually determine a root cause. At that point, you're back to fear driven development, because for every half hour you keep the tree closed, you have 120 engineers unable to commit new code that's nor related to fixing the build failure. Conservatively estimate their salary at $120K/year, then their TCO for computers and everything else is probably $240K/year, and for every half hour you don't open the tree back up, that's ~$14K of lost productivity, and then once you open it up, there's another half hour for the next build to be ready, so even if you react immediately, you're costing the company at least $25K one of those bugs pops on you and you don't just say "screw it" and open the tree back up. Have that happen 3X a day on average, and that's $75K lost money per day, so let's call it $19.5M a year in lost productivity.
This very quickly leads to a "We Fear Change" mentality for anyone making commits. At the very least, it leads to a "We Fear Large Change" mentality which won't stop forward progress, but will insure that all forward progress is incremental and evolutionary. The problem then becomes that you never make anything revolutionary because sometimes there's no drunkard's walk from where you are to the new, innovative place you want to get to (eventually). So you don't g
You said something above... "I am not a writer so can’t speak with authority".
Didn't you mean to say "I am not a writer so can’t write with authority"?
Thanks, enjoy the veal!
Having some experience with both FDD and TDD, I can attest that test driven culture where automated testing is fully integrated into the dev process pretty much addresses all three of your conditions.
The wrong kind of TDD leads to FDD of the type where you're afraid to break the build.
The problem with TDD that leads to this is that TDD is almost totally reactive; that is, you find a bug, you write a test for the bug so you can tell when it's gone; you get rid of the bug, and now you have this test which is going to be run on each build, as if you are not already hyperaware, having both experienced and fixed the bug, of the conditions leading up to the bug. The annoying part, of course, is when you start taking longer and longer amounts of time to get through the build to an acceptance of the build, for each test you add. Then to make things even worse, add to that the occasional false failure because the test is flakey, but it's someone's baby and it "usually works" and the failure is "timing related", and now you're testing the test, and rejecting a perfectly good build because you're unwilling to either rip out the test completely, or make it non-fatal and assign the bug on it back to the person who wrote the original test.
TDD with test cases written up front, and not added to without an associated specification change: Good.
TDD with test cases written to cover historical bugs identified through ad hoc testing: Project Cancer.
The second worst thing you can possibly do is write tests for no good reason because you're able to write tests, but unable to contribute to the core code, and you still want to contribute somehow. The worst thing is being the code reviewer and letting that type of mess into your source tree because you want the person submitting the tests to not feel bad about them not getting accepted.
Or just the better alternative. It is hard to seriously argue that Boeing is so much behind Elon Musk, that anything space related should be given to the latter.
Given that Boeing will already be 3 years late to the party, when SpaceX has manned capability up and running this coming January? We're supposed to wait another couple of years for manned launch capability, when the Russians have already said they wouldn't be hailing our asses into orbit any more? I don't think "Time To Market" is a difficult argument.
One thing Swift will address... There are currently 3 memory management models in use in Objective-C, and for some of those models, you don't get a retain count automatically (for example, this is the case for a number of collection objects when doing an insertion).
Swift has the opportunity to rationalize this, which is not something you could do with the Objective-C libraries themselves, since doing so would change historical APIs and thus break old code.
It wasn't really until Metrowerks basically became incompatible with the Intel switchover and the 64 bit support had to drop certain types of support from Finder due to 64 bit inode numbers, and while I happily would have made them new header files so that they would have continued to work with the UNIX Conformance work, where Ed Moy and I basically broke their local private copies of their header files, since Motorola sold off the Intel version of the Metrowerks C the week because Apple announced Intel, it was pretty much DOA at that point.
So it basically took an Act Of God to get some people to get the hell off some of the old APIs we had been dooming and glooming about for half a decade.
Swift is another opportunity for that type of intentional non-exposure obsolescence to clean up the crappy parts of the APIs and language bindings that haven't been cleaned up previously due to people hanging onto them with their cold, dead hands. Hopefully, they will advantage themselves of this opportunity.
You cannot base any real analysis on figures take by looking at an artists rendering of the site.
Wait. Those weren't artists renderings of actual flying car prototypes on the cover of the Popular Science Magazine covers back in the middle of last century?
Translation:
You can hardly more clear than that. And if Google answers:
Google will not respond to or even read your message
it definitely breaks the law, since this is not even a one sided communication.
The problem here is that the law *requires* an email address. It was never really thought out for large companies with billions of customers, and the law is effectively a bad law as a result, but it is still in fact the law.
I can imagine that the response is going to be something like an IVR system, where you are emailed back something which requires you provide more context ("or you can click here"), and repeats the process narrowing down the context, each time ("or you can go here"), until it drills down to the automated system where it can bucket it into the appropriate web form you should have used in the first place instead of sending them an email, or your problem is answered, or you give up and go away.
Unless there's also a law against IVR in Germany?
Guaranteed that most of these emails to that address are SPAM and/or people bitching about seeing things in the search results they don't want to, or not seeing things in the search results that they expected to, and a human would be telling them, very politely, that nothing will be done about their complaint and/or they are not interested in pretending to be the heir to the fortune on deposit in the Bank of Lagos by the wife of the late oil minister ("now deceased, God Bless").
The fiction of net metering is that you will not be paid the same amount for the electricity you generate as for the electricity you consume.
On of the purposes of "Smart Meters" is to permit differential pricing on electricity produced vs. consumed; it's not just to provide a temporal demand market. There are already tariffs in place in California where PG&E only has to buy as much electricity as you consume for a net 0 energy usage, rather than being required to purchase everything you generate over what you consume.
The idea of a large grid only works if someone pays to maintain that grid, and that pricing comes in as a differential.
Everyone can't do what Tesla is doing because not everyone is going to have the storage capacity to make it economical; Tesla can just rota the batteries it manufactures in service to the manufacturing plant itself, as part of "burn in testing", so that it'll get local off-grid storage as a side effect of the manufacturing process itself.
I suppose that "every rechargeable battery manufacturer can do what Tesla does" would be a fair statement, but that's a tiny subset of "everyone"
Almost everything everyone complains about regarding Facebook is related to its choice of NoSQL as an underlying implementation technology:
- You don't get to see all of your friends posts ... if you pay for the extra work (i.e. step back to ACID)
- Everyone who follows you isn't guaranteed to see all of your posts
- The computational overhead of making ACID guarantees is available
- Posts show up out of order
- A comment on an old post by someone brings the whole thing back as if it's a new post
It follows that the other things that people complain about Facebook over are sure to follow into the NHS implementation, if they are taking that lead to its logical conclusion - meaning advertising replacing desirable content in the medical record.
Great, they've invented "MedBook"... what you see when you look at it is a fraction of the available data at any one time because it has "arrived" at the node where you are viewing it from yet.
What do I have to do so that my drug allergies and blood type are "sponsored postings" so that when my doctor looks at them, he doesn't kill me due to all of the auto-play video advertisements for Cialis being there instead of the information I want to be there?
Museum specimens were commonly preserved with formaldehyde, which damages DNA.
The technique in question would use the DNA from a *lot* of cells. Even if all of them were damaged, they would not be damaged in precisely the same way, which is why the technique works: it's a statistical technique. Give 1500 full specimens with multiple sets of damage, they should, on average, get the full genome for the species, since that's a viable number of individuals to propagate the species.
So again, unless something knocked out a specific chromosome in *all* the cells of *all* the specimens, there's nothing in particular, I'm not seeing the problem here that's being solved by inserting non-species DNA into the genome, since it should be acomplete species genome.it's going to be present in the majority of the samples anyway, and weeding out the damage is a computational bioinformatics task, not a "Well, it's not in this one cell; we're screwed" task.
I'm not understanding "missing DNA"... if they think there is "missing DNA",and they have 1,500 specimens, all less than 2-300 years old, they need to talk to J. Craig Venter, because they're doing it wrong.
I think most are missing the politics.
This is surprising, coming as it does on the heels of Microsoft's refusal to comply with the U.S. Federal court order to hand over overseas held emails.
So I will spell out some of the political consequences here.
The service closure forces a service switch on the remaining people who were using non-Microsoft MSN clients and thus avoiding the Guangming, which operates the Chinese version of Skype, which has been modified "to support Internet regulations", which is to say The Great Firewall of China. If these users want comparable services, the only comparable one now available to them is Tencent’s QQ messaging software, which from the start has been designed "to support Internet regulations". So there are no longer any "too big to shoot in the head" options which do NOT "support Internet regulations".
So really the only people who care about this will be Chinese dissidents who want to communicate with each other using an encrypted channel through a server inaccessible to the Chinese government, and any journalists seeking an encrypted channel whereby they can move information out of China without having to have a government approved satellite uplink handy, or a willingness to smuggle out data storage some other way.
Hardkernel wasn't using Broadcom SoC anyway?
The linked article makes it pretty clear they were basing it on Samsung Exynos SoCs - who *cares* whether or not Broadcom would source them parts, if they weren't even using Broadcom in their design?!? This is like using a Motorola 6502 in a design, and then claiming that Intel wouldn't sell you 8008's ... what the hell?
No, no, no! You have it backwards. Here on Soviet Slashdot, developmental plasticity fish overlords welcome you!
Ironically, it's a revival of Lysenkoism, which has its supportive roots in Soviet era propaganda - making your comment quite apt, given that there was official party support from Stalin, to the point of those opposing the idea being executed. It's gained popularity again due to possible epigenetic mechanisms, but this hasn't really panned out in terms of direct heritability of the induced characteristics.
http://en.wikipedia.org/wiki/L...
We're too cheap to hire a less experienced person and train them to do their job properly.
Get your own training. If I have to train you to do your job properly, I damn well don't want you.
If I wanted to run a training program, I'd open my own version of DeVry University or University of Phoenix. I am in business to do what my business does, and as we are not a vocational education institution, get your freaking vocational education somewhere else.
What you say is partially true.
Companies are not interested in making over someone who isn't a good employee into one. It's the same reason you don't buy burnt out light bulbs, and remanufacture them into working light bulbs yourself, when there are perfectly good light bulbs sitting on the next shelf.
The idea that companies should provide vocational training to potential employees because the educational system has failed to provide them with the ability to be an asset to a potential employer is wrong headed. It is not the responsibility of the employer to make a person employable, it is the responsibility of the person to make themselves employable.
IF we were talking about blue collar manufacturing jobs, or sales/cashier/hamburger jobs, then yeah, apprenticeships and on the job training make sense; in technical areas, it doesn't make sense, any more than it would ti hire someone at a hospital, and on-the-job train them until they were a doctor.
As you surely know, coal plants exhaust is filtered to the extend that the exhaust is cleaner than the intake. At least that is so in germany
Accepting your premise...
It sounds like the Germans need to set up some big filter plants that do nothing but intake, filter, and exhaust the air, if their air is so shitty that running it through a coal fired power plant cleans it.
I have seen first hand a gypsy neighborhood raised by bulldozers.
Apparently, Hillary Clinton was wrong... it doesn't take a village to raise a child, it takes a group of bulldozers.
Any software requiring documentation is broken.
I blame Bob Wallace.
Bob Wallace was one of the originators of the concept of "shareware", and he got paid not for his software. This made people wonder how Quicksoft was able to stay in business.
When questioned about this at one convention, he made circling motions with his hands on either side of his head, and said "Software is ... all up here ... it's not real, it's ephemeral. I don't sell software, I sell manuals". So Quicksoft made its money, and its livelihood in the margin between the cost of mass-producing a manual vs. printing it out from a floppy disk and using up a bunch of tractor feed paper and expensive ribbon.
Or, to put it another way, Quicksoft made their money by having a relatively feature-full product which was nearly impossible to use without documentation. And people have been mistakenly trying to copy his success by utilizing the same technique, ever since.
Why did WordPerfect lose out to Microsoft Word? It wasn't because WordPerfect didn't already own the market; it did. It wasn't because Microsoft Word had more features; it didn't. Was Word a lot better, intrinsically, than WordPerfect? It actually wasn't.
Frankly, it was because of the F1 key. By the time WordPerfect got around to deciding they needed a "Help!" key, some of the function keys were already assigned, and so they assigned the next available one to be the "Help!" key. It helped sell a hell of a lot of keyboard templates. And it hid the help from anyone who'd experimentally go looking for it by hitting unlabeled keys in order until they found it (in fact, this would totally screw you up in WordPerfect).
Microsoft hit on a UX innovation: when something goes wrong, make the "Help!" key the first key someone is likely to hit, before all other keys.
And then they did it one better: The F1 was assigned to be the "Help!" key in *all* their products. Instead of just being a great UX thing, locating the key where they did on the basis of probability, they turned it into a Schelling Point: anyone who wanted "Help!" in any Microsoft product knew where to go to find it, if they had ever used some other Microsoft product, and needed "Help!" there.
So back to the original question: should you invest in documentation? Well, yes... if your product has already failed to the point where it's nearly impossible to use without documentation, or because, like Bob Wallace, you intentionally made it nearly impossible to use without documentation because that's one of the premises of your business model.
Maybe you want to write books on your project, once it's used by enough people to make that profitable, and that's how you plan to turn your hobby into a vacation fund. Or maybe you want to get to be a published author about a product so you get hired as a tech writer somewhere, or you get a lot of speaking engagements, and monetize your efforts that way. But if making your product hard to use was one of your initial conditions, then I think your software is broken.
It is more cute that you don't kniw the difference between waste and spend fuel.
Reprocessing spend fuel produces more waste than not reprocessing, hint: for fuck sake read about the topic instead of making cute comments that in hint seight only show you are a dump ass, and not a smart ass.
It's also cute when someone who can't spell attempts to "correct" a theoretical physicist on a physics topic, and their correction is wrong:
http://www.world-nuclear.org/i...
http://en.wikipedia.org/wiki/N...
Actually, no. Linus has given us Linux and git. Whereas Congress has given us debt slavery, corruption, economic stagnation and Forever War.
I suppose we'll have to take the bad with the good.