"Almost impossible"? Not the majority yet, sure, but that's how a transition happens--with one competitor willing to offer a better deal. Not so long ago it did feel like zero of them. But we do have T-Mobile as the main carrier doing "value" bundles now. There's also reseller Straight Talk though, which piggybacks off AT&T too, and that's a TracFone Wireless / Walmar offering. You can't say something is that hard to find in the US when Walmart carries it. I've also bought from multiple pre-paid wireless services, where buying your phone outright and up-front was a requirement.
Now, if your problem is that coverage of these alternatives isn't very good compared to Verizon, that I'd agree with. It's still a relatively new option, and it hasn't been around long enough to apply economic pressure to Verizon yet. At least it's an option at all now. I am renegotiating my T-Mobile contract with a fully owned phone in hand this upcoming month, and it wasn't that hard to reach this point.
Likely does not mean certain in all cases. The trend toward providing unlocked phones at full price, instead of subsidized ones, will on average save people money. You can of course find a case where it doesn't. In theory having a free market will eventually level such differences, such as how T-Mobile has started unlocking more and focusing on monthly rate to seem competitive. Monopoly situations where there is only one carrier available do not operate as a free market.
You have to make the fine based on the gross sales of the associated product. If this were even 1% of all PS3 and Playstation Store sales, it would be a real fine. Anything else is trivially gamed to zero, the same way taxes are.
Yes, they want to be paid twice for the traffic. Who wouldn't want to be paid twice for the same thing if you could? Orange discovered they had enough leverage on Google that they could, so they did.
The Frame latencies by percentile graph they create now is the right way to look at this data. It's a sort of probability distribution function for slow frames. Nothing simpler will capture the complexity of the problem. You can't usefully boil the universe of rendering latency issues into any single number.
The worst frame will vary based on card and game, and the tools available to reviewers are not practical to find them. And what this debacle has shown is that even though they're limited, the tools being used by reviewers are sometimes better than internal QA at the manufacturers.
My 5.x -> 6.x migration is hosting the 6.x one in a VM. When that works perfectly, I'll extract the image over the existing root disks (after a backup of course).
Your advice is like telling a strait women she should try being a lesbian for a while, because all the good men are already married. You lose time and unless you actually are a lesbian want to be one or find it interesting for its own sake, there isn't much point.
If you're George Strait's wife it is hard to explore other options. Your analogy is otherwise flawed. Here's how that actually works:
Good Man: "I'm already married"
Woman: "That's OK, I've been a lesbian for a while, I wasn't sure if I wanted to dating men again anyway"
Good Man: [dumps current wife]
It's really the best possible training for husband shopping.
The most troublesome Java coders are the ones who see themselves as genius design pattern architects rather than common coders. What drove me away from Java was trying to use libraries with names like AbstractSingletonFactoryBridgeAdapterDecoratorFacadeStrategyObserver. That group has turned using Java from something straightforward you could keep the design of in your head--an underrated benefit of C impacting why C++ never displaced it--into one where you need a tool like Eclipse just to figure out how methods are called.
Yes, GSM phones can easily make a quite audible bit of feedback into the audio range. One of the answers when this came up before goes into why it happens. Thinking that EMI impacting computers is an ancient, solved problem is pretty ridiculous. Anyone who doubts this should move a microwave oven, a wifi receiver, and a 2.4GHz portable phone next to each other until they've realized they're wrong.
That said, the audio signal in the GSM phone ringing case is probably coming through the audio cables outside of the computer case, not from bad PC case shielding.
It's possible to tell someone that they don't need to present so much material at a meeting, with the goal being to make the meetings shorter, without being a dick. It's helpful to have someone with people skills run this sort of thing. They might also deal with the god damn customers so the engineers don't have to.
One of the points of the "scrum master" role is to keep the meetings a reasonable length. The correct response to "someone is always too verbose" is for them to corrected by that person until they stop. If you're going to claim you follow this method, you cannot ever let the time boundary expand to fit however much people want to say. The feedback loop doesn't go in that direction; it goes toward adjusting the inputs until the length is on target.
I'm no fan of Scrum, but I wouldn't presume that it can be replaced entirely by some accountability tools. The "What have you done since yesterday?" part of the meeting can certainly be replaced with a scan of commits, and letting that part of the meeting go on far too long is a problem at a lot of places. Replacing "storytime" with a bug entry that's actually a feature description is also more useful than most ways to save that information. It helps integrate bugs and features into one view of the development state.
But even if you've done all that, the main useful thing the standard Scrum practice can still do is communicate impediments/stumbling blocks. You might say "I'm stuck on X and could use help with Y", brainstorm on the problem, try to allocate resources to help, and figure out how this will impact the long-term schedule. Trying to fit all of that into a bug tracker makes it overbearing for its primary job. You shouldn't expect developers to be tweaking a project planning Gantt chart because they're stuck on something, but it's exactly the sort of thing that should come out of a good Scrum meeting.
When you're "online" having a meeting, pushing a discussion out of it is taking that part "offline". It's not a great way to have co-opted the term, but it's so standard now it's right at the start of the wikipedia entry on online/offline.
Google shelters enormous amounts of their profits through Ireland and the Netherlands. Since they're evading taxes using EU countries, they can't claim they're not bound by the rules of the EU.
"the most efficient way possible". That's an in-place copy like reverse() does, so the question is consistent, implying what it wants in two different ways. Worrying that concurrent, parallel processing Javascript might be involved is a bit of a stretch for this example.
If the less efficient approach of making a non-destructive copy were relevant, the specification should have given that as a priority instead of efficiency. And if that were there, also referencing reverse() would make the requirements fuzzy here--a non-destructive copy isn't like reverse anymore--and I would have flagged this as an unclear question. It's fine as written though.
I've been known to answer questions like this with two implementations and comments about the trade-offs between them. In an interview context that's preferable to asking "what do you really mean?" questions. You could easily write both versions, flagging one as safer for parallel operation than the other. But that one must be marked as the less efficient one, and therefore not the best answer.
An in-place copy is the most efficient way to do it, that part of the question was a hint.
Many algorithms have a space/time trade-off in them. If you're willing to allocate more memory, you can run faster. That makes memory size part of efficiency. Any implementation that uses more memory should see some performance gain in return, before it can be considered more efficient. Creating an array that's the same size of the input is therefore less efficient unless there's some compelling runtime gain possible by doing it. And here that's not the case. An in-place implementation takes trunc(n / 2) array element swap steps, the two array version n array element copy steps. Even if a swap takes longer to do than a copy, the fact that you're touching more memory means slower, including things like CPU data cache disruption.
If this were a C compiler and using a second array allowed using memcpy rather than coding your own loop, you could make a case that there's a more efficient way to do this with more storage. That's different from this problem in two ways though. The target is not that low level of a language, and there's normally no reversing version of a memory copy available.
When interview tests suggest re-implementing a standard library feature, the goal is normally to match it as closely as possible. You shouldn't presume anything about the reasons for that, beyond that it makes a useful test question. If I gave this test and someone arrogant programmer told me I was stupid for asking, because it's already there, I'd point out that you're unlikely to improve on a standard function without bugs if you don't start with cloning it perfectly. Perhaps this is step one toward an improved version, and the next step needs something like it as a regression test harness to validate faster versions. Stopping to complain that you don't understand why you're being asked to do this is also less efficient, relative to just doing it.
You were supposed to reverse the array in-place, the way reverse() does. You created a second one instead, which means you're not even looking at the efficiency of the right type of operations. Welcome to the "didn't pay attention to the spec" part of the circular filing cabinet. I don't write Javascript code, but it only took a second to search for this method to clarify. That was part of the test.
The reaction I've seen from the Thinkpad faithful (a group I've been in a long time) on forums.lenovo.com seems evenly split on whether the new keys feel better or not. Regardless, the layout change is unambiguously worse for what I do, making that a net negative. What they did to the top row is just terrible. The layout is no better than every other keyboard on the market.
And that's really the point. They're still reasonable laptops, especially given the rest of the competition has gone downhill. But too much of what made the Thinkpads uniquely good has been chiseled away for me now. There was no other laptop on the planet I'd have traded my T60s, which are still chugging away, for. I struggled with motherboard failures in the T61, a buggy TPM and a BIOS update that bricked the unit on the T500, video out not working right on the T520--all things I saw multiple other reports of too. Losing the old keyboard layout and having to adjust to a new keyboard feel on the T530 was just the last straw. I can use a Mac, with its equally bad top row, or a new Thinkpad, and it doesn't matter to me anymore.
No argument that the repairability on the Thinkpads is still by far the market leader. The 15" Macbook Pros can still be worked on, but the smaller Macs are well nigh unrepairable.
Also, some (almost all?) ODBC and database servers send passwords in the clear.
Many database servers allow encrypted passwords, but there are surely a lot of database installations that don't take advantage of it. In PostgreSQL you can use SSL for the client network connection, which ODBC passes through. Setup SSL as the only way to connect, and encryption has to happen before it hits the wire. MySQL has a similar trick. Both are just using the OpenSSL library under the hood to encrypt the network traffic.
On the commercial side, Oracle does the same thing with ORA_ENCRYPT_LOGIN. SQL Server has client and server settings that enforce encryption. Basically, if your database traffic isn't encrypted, it's more likely because someone didn't think that was important than because it was impossible. It's a simple checkbox to add to database selection requirements, and it's not hard to find a DBMS that has the capability.
I find people who just stuff user passwords into the database (which can be the same passwords as other services) rather than putting password encryption into their application can also leak data. In PostgreSQL using the built-in pgcrypto makes that easy. You also have to be careful to use the same network encryption approach for any replication client, or it's possible to just sniff that instead to get the data. In Postgres those connect with the same encryption possible options as any other client. Most of the tutorials on setting up replication don't cover this though.
Just a small heads up, breaking the TOS is not illegal. The only thing that could happen is a possible civil suit.
Also, Aaron Swartz is working hard on RSS 3.0, your check is in the mail, and I would never cum in your mouth, baby!
"Almost impossible"? Not the majority yet, sure, but that's how a transition happens--with one competitor willing to offer a better deal. Not so long ago it did feel like zero of them. But we do have T-Mobile as the main carrier doing "value" bundles now. There's also reseller Straight Talk though, which piggybacks off AT&T too, and that's a TracFone Wireless / Walmar offering. You can't say something is that hard to find in the US when Walmart carries it. I've also bought from multiple pre-paid wireless services, where buying your phone outright and up-front was a requirement.
Now, if your problem is that coverage of these alternatives isn't very good compared to Verizon, that I'd agree with. It's still a relatively new option, and it hasn't been around long enough to apply economic pressure to Verizon yet. At least it's an option at all now. I am renegotiating my T-Mobile contract with a fully owned phone in hand this upcoming month, and it wasn't that hard to reach this point.
Only terrorists unlock their phones illegally! Enjoy your stay at the FEMA camp!
Likely does not mean certain in all cases. The trend toward providing unlocked phones at full price, instead of subsidized ones, will on average save people money. You can of course find a case where it doesn't. In theory having a free market will eventually level such differences, such as how T-Mobile has started unlocking more and focusing on monthly rate to seem competitive. Monopoly situations where there is only one carrier available do not operate as a free market.
If your developer claims they are "putting in the extra 110% effort" I don't even want to know about the off by one errors in their code.
You have to make the fine based on the gross sales of the associated product. If this were even 1% of all PS3 and Playstation Store sales, it would be a real fine. Anything else is trivially gamed to zero, the same way taxes are.
Yes, they want to be paid twice for the traffic. Who wouldn't want to be paid twice for the same thing if you could? Orange discovered they had enough leverage on Google that they could, so they did.
The Frame latencies by percentile graph they create now is the right way to look at this data. It's a sort of probability distribution function for slow frames. Nothing simpler will capture the complexity of the problem. You can't usefully boil the universe of rendering latency issues into any single number.
The worst frame will vary based on card and game, and the tools available to reviewers are not practical to find them. And what this debacle has shown is that even though they're limited, the tools being used by reviewers are sometimes better than internal QA at the manufacturers.
I like (650) 543-4800. That is of course Facebook's customer service number.
My 5.x -> 6.x migration is hosting the 6.x one in a VM. When that works perfectly, I'll extract the image over the existing root disks (after a backup of course).
Your advice is like telling a strait women she should try being a lesbian for a while, because all the good men are already married. You lose time and unless you actually are a lesbian want to be one or find it interesting for its own sake, there isn't much point.
If you're George Strait's wife it is hard to explore other options. Your analogy is otherwise flawed. Here's how that actually works:
It's really the best possible training for husband shopping.
In Soviet Russia Java exploits you!
The most troublesome Java coders are the ones who see themselves as genius design pattern architects rather than common coders. What drove me away from Java was trying to use libraries with names like AbstractSingletonFactoryBridgeAdapterDecoratorFacadeStrategyObserver. That group has turned using Java from something straightforward you could keep the design of in your head--an underrated benefit of C impacting why C++ never displaced it--into one where you need a tool like Eclipse just to figure out how methods are called.
They offer a hosted service, they don't give the exploits to customers.
When I said before that I couldn't have any less respect for things hosted "in the cloud" for no good reason, I see I was wrong.
Yes, GSM phones can easily make a quite audible bit of feedback into the audio range. One of the answers when this came up before goes into why it happens. Thinking that EMI impacting computers is an ancient, solved problem is pretty ridiculous. Anyone who doubts this should move a microwave oven, a wifi receiver, and a 2.4GHz portable phone next to each other until they've realized they're wrong.
That said, the audio signal in the GSM phone ringing case is probably coming through the audio cables outside of the computer case, not from bad PC case shielding.
It's possible to tell someone that they don't need to present so much material at a meeting, with the goal being to make the meetings shorter, without being a dick. It's helpful to have someone with people skills run this sort of thing. They might also deal with the god damn customers so the engineers don't have to.
One of the points of the "scrum master" role is to keep the meetings a reasonable length. The correct response to "someone is always too verbose" is for them to corrected by that person until they stop. If you're going to claim you follow this method, you cannot ever let the time boundary expand to fit however much people want to say. The feedback loop doesn't go in that direction; it goes toward adjusting the inputs until the length is on target.
I'm no fan of Scrum, but I wouldn't presume that it can be replaced entirely by some accountability tools. The "What have you done since yesterday?" part of the meeting can certainly be replaced with a scan of commits, and letting that part of the meeting go on far too long is a problem at a lot of places. Replacing "storytime" with a bug entry that's actually a feature description is also more useful than most ways to save that information. It helps integrate bugs and features into one view of the development state.
But even if you've done all that, the main useful thing the standard Scrum practice can still do is communicate impediments/stumbling blocks. You might say "I'm stuck on X and could use help with Y", brainstorm on the problem, try to allocate resources to help, and figure out how this will impact the long-term schedule. Trying to fit all of that into a bug tracker makes it overbearing for its primary job. You shouldn't expect developers to be tweaking a project planning Gantt chart because they're stuck on something, but it's exactly the sort of thing that should come out of a good Scrum meeting.
When you're "online" having a meeting, pushing a discussion out of it is taking that part "offline". It's not a great way to have co-opted the term, but it's so standard now it's right at the start of the wikipedia entry on online/offline.
Google shelters enormous amounts of their profits through Ireland and the Netherlands. Since they're evading taxes using EU countries, they can't claim they're not bound by the rules of the EU.
"the most efficient way possible". That's an in-place copy like reverse() does, so the question is consistent, implying what it wants in two different ways. Worrying that concurrent, parallel processing Javascript might be involved is a bit of a stretch for this example.
If the less efficient approach of making a non-destructive copy were relevant, the specification should have given that as a priority instead of efficiency. And if that were there, also referencing reverse() would make the requirements fuzzy here--a non-destructive copy isn't like reverse anymore--and I would have flagged this as an unclear question. It's fine as written though.
I've been known to answer questions like this with two implementations and comments about the trade-offs between them. In an interview context that's preferable to asking "what do you really mean?" questions. You could easily write both versions, flagging one as safer for parallel operation than the other. But that one must be marked as the less efficient one, and therefore not the best answer.
An in-place copy is the most efficient way to do it, that part of the question was a hint.
Many algorithms have a space/time trade-off in them. If you're willing to allocate more memory, you can run faster. That makes memory size part of efficiency. Any implementation that uses more memory should see some performance gain in return, before it can be considered more efficient. Creating an array that's the same size of the input is therefore less efficient unless there's some compelling runtime gain possible by doing it. And here that's not the case. An in-place implementation takes trunc(n / 2) array element swap steps, the two array version n array element copy steps. Even if a swap takes longer to do than a copy, the fact that you're touching more memory means slower, including things like CPU data cache disruption.
If this were a C compiler and using a second array allowed using memcpy rather than coding your own loop, you could make a case that there's a more efficient way to do this with more storage. That's different from this problem in two ways though. The target is not that low level of a language, and there's normally no reversing version of a memory copy available.
When interview tests suggest re-implementing a standard library feature, the goal is normally to match it as closely as possible. You shouldn't presume anything about the reasons for that, beyond that it makes a useful test question. If I gave this test and someone arrogant programmer told me I was stupid for asking, because it's already there, I'd point out that you're unlikely to improve on a standard function without bugs if you don't start with cloning it perfectly. Perhaps this is step one toward an improved version, and the next step needs something like it as a regression test harness to validate faster versions. Stopping to complain that you don't understand why you're being asked to do this is also less efficient, relative to just doing it.
You were supposed to reverse the array in-place, the way reverse() does. You created a second one instead, which means you're not even looking at the efficiency of the right type of operations. Welcome to the "didn't pay attention to the spec" part of the circular filing cabinet. I don't write Javascript code, but it only took a second to search for this method to clarify. That was part of the test.
The reaction I've seen from the Thinkpad faithful (a group I've been in a long time) on forums.lenovo.com seems evenly split on whether the new keys feel better or not. Regardless, the layout change is unambiguously worse for what I do, making that a net negative. What they did to the top row is just terrible. The layout is no better than every other keyboard on the market.
And that's really the point. They're still reasonable laptops, especially given the rest of the competition has gone downhill. But too much of what made the Thinkpads uniquely good has been chiseled away for me now. There was no other laptop on the planet I'd have traded my T60s, which are still chugging away, for. I struggled with motherboard failures in the T61, a buggy TPM and a BIOS update that bricked the unit on the T500, video out not working right on the T520--all things I saw multiple other reports of too. Losing the old keyboard layout and having to adjust to a new keyboard feel on the T530 was just the last straw. I can use a Mac, with its equally bad top row, or a new Thinkpad, and it doesn't matter to me anymore.
No argument that the repairability on the Thinkpads is still by far the market leader. The 15" Macbook Pros can still be worked on, but the smaller Macs are well nigh unrepairable.
Also, some (almost all?) ODBC and database servers send passwords in the clear.
Many database servers allow encrypted passwords, but there are surely a lot of database installations that don't take advantage of it. In PostgreSQL you can use SSL for the client network connection, which ODBC passes through. Setup SSL as the only way to connect, and encryption has to happen before it hits the wire. MySQL has a similar trick. Both are just using the OpenSSL library under the hood to encrypt the network traffic.
On the commercial side, Oracle does the same thing with ORA_ENCRYPT_LOGIN. SQL Server has client and server settings that enforce encryption. Basically, if your database traffic isn't encrypted, it's more likely because someone didn't think that was important than because it was impossible. It's a simple checkbox to add to database selection requirements, and it's not hard to find a DBMS that has the capability.
I find people who just stuff user passwords into the database (which can be the same passwords as other services) rather than putting password encryption into their application can also leak data. In PostgreSQL using the built-in pgcrypto makes that easy. You also have to be careful to use the same network encryption approach for any replication client, or it's possible to just sniff that instead to get the data. In Postgres those connect with the same encryption possible options as any other client. Most of the tutorials on setting up replication don't cover this though.