The guest doesn't need to leave with the key, they just need to make a copy. Are you going to change the lock between every 2 customers? No? Then electronics are more secure, for hotels (homes/businesses are a different set of problems).
Because non-electronic doors are worse. With electronic door, you kill the key if it isn't turned in, and they can't get back into the room. With a physical key, you can trivially make a copy which will allow you access later- when someone else is renting the room. Electronic keys are safer for guests.
You can, but you still have to claim all the permissions you could use. That's the way the permissions work- you put them all int he manifest, and all are shown when you download it. (Then on modern android some permissions require you to ask again at runtime).
An every keyboard written today is written this way. What are you going to do, ship every language to every phone regardless of if it will be used? Of course not, you download the dictionaries at runtime. You'll find few to no keyboards without a network connection of some type.
It would be. They seem to be going the other way though- bundling permissions in permission groups on the play store listings. At least now you can turn them on and off individually, and well written apps will still work.
I worked with the people who wrote the feature. I also have seen it in action as a user- when I went to Spain a large number of local places like the Segrada Familia went into the dictionary. I can assure you that was absolutely what it was added for (and it only used approximate location, no need to know the location to more than city). Whether its been increased in scope in the last few years I couldn't tell you, I left the company in May 2012.
Actually it doesn't, that level of data can be stored on the client (and generally is). Its simple n-grams. Keeping it up to date would require network access.
Depends on the implementation of the keyboard. If the keyboard has downloadable components, such as parts written in javascript, or datafiles then downloadable updates could include security fixes.
They made an agreement, and now they need to back out of it due to their own fault (they bought the crappy software or misconfigured it). Paying the pilot some money to change plans that they made depending on the promise made to them seems reasonable.
It has multiple pictures of you. Notice the feature whenever you upload photos and it asks you to tag others- and generally knows who's in the photo? Yes, it knows what you look like.
The mobile apps track your location. You can turn it off at the OS level, but if you don't do that it absolutely knows you location.
It knows your friends, or at least the vast majority of them. If you're about to say that your friends list isn't really your friends- it has correlation scores for how close any two people are. They aren't 100%, but they're damn close.
Your interests- they know everything you like, everything you post or DM about. Through those little like buttons on almost every webpage, they know a good 95% of your web traffic. They know all to almost all your interests.
If you're in a relationship or not- well there's a place to list it that lots of people use. And a high enough friendship coefficient between people of the correct orientation is a pretty good guess if you don't.
What other pages you look at on the web- yes they do. That's the purpose of the like button.
Some small percentage of people may take extraordinary efforts to avoid this- but that's what it takes. They have this info on pretty much everyone.
Not so much that, but more that NOT EVERY JOB out there is meant to be made a career of, nor sole source of income to support yourself/family.
No, absolutely wrong. If it isn't worth paying a living wage to be done, then we as a society don't need the work done, and the business owner can do it his fucking self. If they don't like that, pay a living wage.
Define "the simplest and most straight forward way to do it". That isn't the same for everyone. Some people like functional programming and streams of lambdas. Some of us find that style utterly unmaintainable. Even in your statement: "in order to improve code density"- code density doesn't mean its better and past a certain amount its actually undesirable. Dense code is harder to read, and more difficult to maintain without subtle breaks.
The same bullshit logic can apply to personal taxes. I don't pay taxes, they cause me to adjust my salary requirements upwards as I pass them on to my employer. So personal taxes are taxes on corporations.
Now we can get back to reality, where prices are not infinitely flexible and passing onto consumers is not an actual thing. By artifically attempting to pass on the prices they slide down on the supply curve to and sell fewer items. Who bares the brunt of that difference? The company. Or they don't change their price and sell the same amount. Again the company bears that (and indirectly stockholders and employees).
So yes, corporate taxes are a real thing, and aren't indirect taxes on consumers. Learn some fucking economics instead of right wing talking points.
Yeah- the number of people who would actually understand and download two apps to get the full features of one app is approximately 0. I'd be confused and not trust it as a programmer- forget nontech savy
They can- but they lose the easiest way of advertising and promoting their apps. Getting people to do it from the playstore is hard enough, getting people to do it from a website is an order of magnitude harder.
Because a lot of times they're pushing the boundaries of what Google has even thought of doing.
For example, I wrote some software that uses accessibility to get the text of other apps and send it to Google translate so I can get in app translation of things not written in English. There's no API to do that.
I worked at Facebook. We had graphs of ages of users. Basically, it stayed low until a spike at 18 (when people went to college) and a huge spike at 22 (graduating college). Facebook isn't so much for old people, as it is for people who want to keep up with old friends. Until you're old enough to have those it has lower value.
You're either not trying, or you're a really bad programmer. Let's try this:
if(x) { //enable Feature A } if(y) { //enable Feature B }
What if Feature A and B are incompatible. Turning on B and A at the same time breaks the entire app. The fact we can try to enable both at the same time is a bug.
You can have 100% code coverage without ever testing what happens if x and y are both true, by testing x=true y=false and x=false y=true. You would then test each line, and say you had 100% coverage. But you wouldn't be testing every way the app can be run, and would be missing bugs. The 100% number is pointless, it isn't well tested.
If you still don't get it- find another profession, you're not competent in this one.
Because the 100% measures lines independently. It doesn't mean that combinations of branch statements/loop iterations are tested. Without which, you claim to be testing 100% but are really testing some unknown but much lower percentage of actual code paths. Just running each line once has 0 actual value, it doesn't mean the code is well tested. I would rather have a suite that actually tests some subset of the code exhaustively than a suite that runs each line once and claims that everything is perfectly tested.
Actually you're perfectly illustrating my point of why the number is garbage. You actually think 100% code coverage means you have good tests. Its completely tangential.
No it isn't. 100% means every line is run once. That 50% case may only run part of the code base, but it may cover a subsystem completely with all combo of options. I'll take the second over the first. Which is why code coverage numbers are worthless. We have no idea which of those two situations it is based on the numbers.
Except you're wrong and all of those can and do fool a variety of fingerprint sensors. Given the newness of the technology I trust facial recognition even less. I'll stick with a pin or password, thanks.
Slashdot Mirror
The guest doesn't need to leave with the key, they just need to make a copy. Are you going to change the lock between every 2 customers? No? Then electronics are more secure, for hotels (homes/businesses are a different set of problems).
Because non-electronic doors are worse. With electronic door, you kill the key if it isn't turned in, and they can't get back into the room. With a physical key, you can trivially make a copy which will allow you access later- when someone else is renting the room. Electronic keys are safer for guests.
You can, but you still have to claim all the permissions you could use. That's the way the permissions work- you put them all int he manifest, and all are shown when you download it. (Then on modern android some permissions require you to ask again at runtime).
An every keyboard written today is written this way. What are you going to do, ship every language to every phone regardless of if it will be used? Of course not, you download the dictionaries at runtime. You'll find few to no keyboards without a network connection of some type.
It would be. They seem to be going the other way though- bundling permissions in permission groups on the play store listings. At least now you can turn them on and off individually, and well written apps will still work.
I worked with the people who wrote the feature. I also have seen it in action as a user- when I went to Spain a large number of local places like the Segrada Familia went into the dictionary. I can assure you that was absolutely what it was added for (and it only used approximate location, no need to know the location to more than city). Whether its been increased in scope in the last few years I couldn't tell you, I left the company in May 2012.
Actually it doesn't, that level of data can be stored on the client (and generally is). Its simple n-grams. Keeping it up to date would require network access.
Having worked at Swype, I can tell you why most of those are there.
Record audio- see the voice recognition button? Required for it to work. Lots of people like voice recognition
Get my approximate and precise location- download dictionaries of local places that wouldn't be in the normal dictionary.
Read my text messages- train autocorrect algorithms
Full network access- upload dictionaries to the server/download your dictionaries to a new device. Also their whole theme download store.
Pair with Bluetooth devices- bluetooth headsets
Read my contacts- we scan your contacts to add the names to the dictionary, so it will allow you to type your friend's names.
Read terms I've added to the dictionary- Swype has its own dictionary, but if you added any to the device's we want to add those to ours
Read phone status and identity- literally this was to turn off typing noises when on speakerphone
Modify or delete the contents of my USB storage- to allow you to store the dictionary on a connected device, if you wanted
If you want a smooth app that integrates with the OS well, you're going to need a lot of permissions. There's just no way around it.
Depends on the implementation of the keyboard. If the keyboard has downloadable components, such as parts written in javascript, or datafiles then downloadable updates could include security fixes.
That's kindle paperwhites, not Fire tablets. Fires have normal screens. They also have shit for sales.
They made an agreement, and now they need to back out of it due to their own fault (they bought the crappy software or misconfigured it). Paying the pilot some money to change plans that they made depending on the promise made to them seems reasonable.
It has multiple pictures of you. Notice the feature whenever you upload photos and it asks you to tag others- and generally knows who's in the photo? Yes, it knows what you look like.
The mobile apps track your location. You can turn it off at the OS level, but if you don't do that it absolutely knows you location.
It knows your friends, or at least the vast majority of them. If you're about to say that your friends list isn't really your friends- it has correlation scores for how close any two people are. They aren't 100%, but they're damn close.
Your interests- they know everything you like, everything you post or DM about. Through those little like buttons on almost every webpage, they know a good 95% of your web traffic. They know all to almost all your interests.
If you're in a relationship or not- well there's a place to list it that lots of people use. And a high enough friendship coefficient between people of the correct orientation is a pretty good guess if you don't.
What other pages you look at on the web- yes they do. That's the purpose of the like button.
Some small percentage of people may take extraordinary efforts to avoid this- but that's what it takes. They have this info on pretty much everyone.
No, absolutely wrong. If it isn't worth paying a living wage to be done, then we as a society don't need the work done, and the business owner can do it his fucking self. If they don't like that, pay a living wage.
Define "the simplest and most straight forward way to do it". That isn't the same for everyone. Some people like functional programming and streams of lambdas. Some of us find that style utterly unmaintainable. Even in your statement: "in order to improve code density"- code density doesn't mean its better and past a certain amount its actually undesirable. Dense code is harder to read, and more difficult to maintain without subtle breaks.
The same bullshit logic can apply to personal taxes. I don't pay taxes, they cause me to adjust my salary requirements upwards as I pass them on to my employer. So personal taxes are taxes on corporations.
Now we can get back to reality, where prices are not infinitely flexible and passing onto consumers is not an actual thing. By artifically attempting to pass on the prices they slide down on the supply curve to and sell fewer items. Who bares the brunt of that difference? The company. Or they don't change their price and sell the same amount. Again the company bears that (and indirectly stockholders and employees).
So yes, corporate taxes are a real thing, and aren't indirect taxes on consumers. Learn some fucking economics instead of right wing talking points.
Yeah- the number of people who would actually understand and download two apps to get the full features of one app is approximately 0. I'd be confused and not trust it as a programmer- forget nontech savy
They can- but they lose the easiest way of advertising and promoting their apps. Getting people to do it from the playstore is hard enough, getting people to do it from a website is an order of magnitude harder.
Because a lot of times they're pushing the boundaries of what Google has even thought of doing.
For example, I wrote some software that uses accessibility to get the text of other apps and send it to Google translate so I can get in app translation of things not written in English. There's no API to do that.
I worked at Facebook. We had graphs of ages of users. Basically, it stayed low until a spike at 18 (when people went to college) and a huge spike at 22 (graduating college). Facebook isn't so much for old people, as it is for people who want to keep up with old friends. Until you're old enough to have those it has lower value.
You're either not trying, or you're a really bad programmer. Let's try this:
What if Feature A and B are incompatible. Turning on B and A at the same time breaks the entire app. The fact we can try to enable both at the same time is a bug.
You can have 100% code coverage without ever testing what happens if x and y are both true, by testing x=true y=false and x=false y=true. You would then test each line, and say you had 100% coverage. But you wouldn't be testing every way the app can be run, and would be missing bugs. The 100% number is pointless, it isn't well tested.
If you still don't get it- find another profession, you're not competent in this one.
Because the 100% measures lines independently. It doesn't mean that combinations of branch statements/loop iterations are tested. Without which, you claim to be testing 100% but are really testing some unknown but much lower percentage of actual code paths. Just running each line once has 0 actual value, it doesn't mean the code is well tested. I would rather have a suite that actually tests some subset of the code exhaustively than a suite that runs each line once and claims that everything is perfectly tested.
Actually you're perfectly illustrating my point of why the number is garbage. You actually think 100% code coverage means you have good tests. Its completely tangential.
No it isn't. 100% means every line is run once. That 50% case may only run part of the code base, but it may cover a subsystem completely with all combo of options. I'll take the second over the first. Which is why code coverage numbers are worthless. We have no idea which of those two situations it is based on the numbers.
Still meaningless.
You can have 100% without testing the combo of foo and bar. WHich could break everything. Code coverage numbers just give a false sense of security.
They can very easily grab my face- just grab the phone and hold it up. You really are an idiot aren't you?
Except you're wrong and all of those can and do fool a variety of fingerprint sensors. Given the newness of the technology I trust facial recognition even less. I'll stick with a pin or password, thanks.