'Zactly. There are PILES of PHP and Perl snippet that filter quotes, or allow Unicode.
I have tried typing Russian (Cyrillic) and Persian (Arabic-derived) into the site in the past. Ouch.
I had a steady weight for about 2-3 years and started drinking a lot of diet soda and gained 10 pounds. I have cut it out almost entirely (before I saw this study, in fact) and I'll see what happens. I still do like carbonated beverages, so I've switched to an unsweetened, naturally flavoured carbonated drink in a can ("Pure Life" by Nestle. Water, CO2, flavour). I was drinking soda water for awhile but the lack of taste eventually made me lose interest, plus there's salt in it.
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.
I still find slashdot entertaining, due to the humour, the culture, etc... I just don't learn much from it any more. Back in the early days, there was always something new to be learned about technology, open source, computer security. I think both slashdot and I have evolved. I simply know more now, and slashdot might have gone down a the drain a little bit. However, I say that with the knowledge that other forums never even had the level of conversation one gets here, even now.
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 go there.
The whole "We Fear Large Change" mentality - the anti-innovation mentality - tends to creep in any place you have the Agile/SCRUM coding pattern, where you're trying to do large things in small steps, and it's just not possible to, for example, change an API out from everyone, without committing changes to everyone else at the same time.
You can avoid the problem (somewhat) by adding the new API before taking the old API away. So you end up with things like "stat64" that returns a different structure from "stat", and then when you go and try to kill "stat" after you've changed everywhere to call "stat64" instead, with the new structure, you have to change the "stat" API to be the same as the "stat64" API, and then convert all the call sites back, one by one, until you can then get rid of the "stat64".
That leads to things like Solaris, where the way you endure binary compatibility is "give the hell up; you're never going to kill off the old stat, just live with carrying around two APIs, and pray people use the new one and you can kill off the old one in a decade or so". So you're back to another drunkard's walk of very slow progress, but at least you have the new API out of it.
And maybe someday the formal process around the "We Fear Change" mentality, otherwise known as "The Architectural Board" or "The Change Control Committee" or "Senior VP Bob" will let you finally kill off the old API, but you know, at that point, frankly you don't care, and the threat to get rid of it is just a bug in a bug database somewhere that someone has helpfully marked "NTBF" because you can close "Not To Be Fixed" bugs immediately, and hey, it gets the total number of P2 or P3 bugs down, and that looks good on the team stats.
I have been in a few jobs where the managers were verbally and/or emotionally abusive. In both cases I left ASAP.
THIS. Life's too short to put up with loser companies.
That being said, one needs a financial cushion of 6 months-ish. The easiest way to do that is to skim off 10% from every paycheck, no matter what.
Remember, you canâ"and should!â"evaluate the company you work for, daily. If they "fail the interview" (i.e., it is more hassle to work there than to find another job) then it is time to Let Them Go.
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!
Convert to Islam or die.
This is not, nor has it ever been a central tenet of Islam. This cannot be viewed in political or historical isolation.
"Convert to Christianity under Papal authority or die by red-hot poker" was a governing principal of church and state - at the center of Europe's most powerful empire, for nearly 200 years. It was never the message of Jesus, regardless of your belief in Christianity. But scripture and political expropriation of pseudo-theology made that it seem so.
I hope someday you have a daughter who marries a an African Muslim. You might be forced to reconsider many of the things that you "know" so assuredly.
It's so much EASIER than THINKING!
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.
The US Constitution was an open declaration of treason against the Crown, which at the time controlled the most powerful military the world had ever seen. It was signed by farmers, lawyers, and doctors who had little in the way of protection against that army and little chance of surviving the fight. To say it was anything less than a suicide pact is absurd. The fact that few alive in this country today have their intestinal fortitude speaks volumes to why we're in decline. They had balls. Somewhere along the way, we lost them.
And if you don't think voting leads to people dying, you aren't paying attention.
You're a racist cunt. People are people, and want/need basically the same things - if you don't push them into corners and poke at them with sticks.
The thugs? Products of our selective, post-colonial domination. Nobody rallies round a bully, when they have nothing much to fear.