English almost always drops the pronoun in the imperative, for example like Portuguese and the familiar form of you in German. English doesn't really ever drop the subject of the sentence otherwise...
Sure, it does. If you're talking casually with friends, it's pretty common to drop the initial pronoun, especially when it's implied from context... which is exactly what happens in Japanese, except the context is larger.
|Technically this means I can bring my dog literally anywhere
Doesn't the article specifically state the law only allows keeping an ESA in a residence that doesn't otherwise allow animals, and flying with them for free? The author explicitly states emotional support animals do not have the same rights as service animals, and you cannot bring your dog anywhere. People are just lead to believe so.
I've worked in labs with far less threatening (but still deadly) microorganisms and I could never imagine making a mistake with such a giant flask. It had to have been mislabelled or maybe someone used used autoclave tape to seal something on the top? Only a idiot would pour an unlabelled solution of that size down the drain...
"But if there were ever a disease for which this is not a big deal, it is Ebola. It seems extraordinarily unlikely that the drug could make matters any worse for an Ebola patient than they are already."
It can increase the mortality from 50%-60% to 100%. It can protract death, make it more painful, instill false hope.
It IS extraordinarily unlikely that a drug, tested in animals, will cause a worse result than one of the worst diseases we've ever seen. Concern about "false hope" is bizarre to me - it's not like this is a long-term disease like cancer, where false hope can damage a graceful death and grieving process. It's going to be over for these patients, usually brutally, in days.
That's the point: these are experimental treatments. We don't know. And experimental human treatments have gone bad for no reason at all -> http://en.wikipedia.org/wiki/TGN1412
A drug might make things worse, it could allow a patient to live a bit longer after their friends have rescued them from the isolation ward and enable them to infect more people.
People in IT are assholes. I've only worked in retail, food, biotech and IT but IT has been my least favorite because of my coworkers. I see the shitty attitude is just an in-general IT thing and accepted.
a friend of mine once told me that everyone in Phoenix is an asshole. I laughed and pointed out that there was no way she had met even a significant fraction of people, that human relationships are built with all sorts of biases, and there was no way she could make that assessment without generalizing to the point of uselessness.
she called me an asshole in reply.
you have pretty much the same problem here. you have no reasonable basis upon which to make that statement. it is offensive and generalized to the point of uselessness.
Generalize much? I have worked in different teams.
The "being an-unfriendly-*" problem has often to do with tight timelines and problems/bugs that seem completely weird. Frankly, that can drive you nuts.
It's not really an excuse, but it can probably explain some behavior.
I wouldn't say it's accepted. IT and engineering staff are often given very little respect outside of their own departments in organizations, but they're tolerated.
I hope we see the "shitheads get ahead" mentality give way, or at least recognize that we're first and foremost facilitators of business and that working to earn respect from coworkers is an important part of that.
And those people deserve a special place of torment all their own. How hard is it really to update, or at least delete comments that are no longer relevant when you modify the code?
The comments are meant to be read and used to understand code. So you must test them like any other artifact to ensure that they are a net positive and not a net negative. Programmers make mistakes, which hopefully fail a test or at least cause a crash. Because comments can't be executed, neither of those will happen; they have to be verified manually
Only when all comments only refer to local information. There is nothing to check that the comment in that other file that refers to this code was correctly updated.
Some system of backrefs could handle this, of course, but I'm not aware of anything in use...
> Only when all comments only refer to local information. There is nothing to check that the comment in that other file that refers to this code was correctly updated.
The only time a comment should refer to non-local information is to document an assumption or basis of the local code, which is still correct information about the local code as long as it is the assumption/basis of the local code, even if the assumption is (or later becomes) false.
Of course, it would be useful to have a way to verify the information about the assumptions to see if they have become false, but that's not about validating the comment, that's about validating the code it comments, since if the assumption is false, it is quite likely that the code needs to change (and this may not be something that unit testing the local code can discover, as such comments often are not about correctness but about choosing a less-than-obvious alternative correct approach for optimization, or to work around a quirk of the code being called, etc.)
I'm not sure I disagree. In practice, though, I certainly encounter comments communicating nonlocal information ("This is used in ..."), and of course these are the least likely to remain accurate. "All comments is local" is something we should start drumming into people - I don't think anyone ever said this to me explicitly.
Yes, what I mean is, if you're doing code review then there's virtually no additional cost - you're looking over the changes anyway. It doesn't matter that the process is manual if you're already doing it. If you're not doing code review, then you perhaps either have some organisational issues or you have coworkers who are sufficiently responsible that you can trust them to do basic code hygiene work like keeping comments up to date.
I think comments would be more difficult to review than code, since you'd have to carefully make sure they are meaningful by examining the code, without the context of the programmers involved. Alternatively, you could add comments during code review to document the review and basically redo the comments on each review...maybe.
Comments also break flow and get in the way of code reading, but could probably just be hidden during review.
> I think comments would be more difficult to review than code, since you'd have to carefully make sure they are meaningful by examining the code, without the context of the programmers involved.
Actually, that only makes them hard to review if you are trying too hard, which defeats the purpose of reviewing comments -- if it is hard to validate the utility of a comment without the context of the programmer involved, its a bad comment and needs, at a minimum, to be clarified.
After all, the whole point of a comment is to communicate information to a future person who lacks the context of the programmer involved.
It's manual whether with a tool or without. We like using a tool because it automates the process. We find teams are more thorough in their reviews with a tool. We're also distributed, so it helps with collaboration too.
If you could use NLP to verify the comment, then what would the point of the comment be? Comments are for those aspects of a program that are invisible to the compiler and IDE, the intent.
Maybe my view of NLP is more sci-fi than reality, but I think you're missing what I meant. If you can use NLP to prove that your comment - ie the intent - which IS invisible to the compiler and IDE, then that might be cool. Practical, probably not. But I'd still be very impressed at the implications if this was possible within some error margin.
That's why good comments are about explaining WHY you're doing something, or HOW to use the code, and possibly making the code itself clearer but only if there's no way to do that by introducing better variable and method naming.
Comments are highly valuable but like any tool they can be abused, or done in such a way that they don't make things better.
Companies pretty much do hate working with physical cash - it is heavy, difficult to secure, prone to theft etc.
This was the genius of offering "cashback" when doing a card transaction at somewhere like a supermarket - it is a real win-win - the customer gets cash they might need for something and the supermarket reduces the amount of cash they have to deal with.
The terminals need to send sales data, receive updates of all kinds, and be available for remote access. I do POS support and connect to stores all over the world via public IP for troubleshooting.
It depends how you look at it. Worldwide you are right but Android dominates largely due to the availability of cheap handsets (most of which aren't running the latest Android with the modern flat design style).
In the US iPhone is 40% of the market and considering that 80=90% of users have upgraded to iOS 7 the number of iOS users that are using the flat design compared to the number of Android users with flat design is probably a lot closer than market share would indicate.
Also, although they have less than 25% of the market they are still the second largest manufacturer which in my opinion makes them a 'major hold out'.
