Mainly so that the owner can monitor it remotely in case of problems. But even then it probably makes more sense to set it once and have it sms maintenance if something goes out of range.
Its a thermostat. When I'm cold, I'll walk over and turn it up. When I'm warm, I'll walk over and turn it down. I don't need it to be internet enabled, and don't want the annoyance of some bug or exploit fiddling with it. Not everything needs to be set from your smartphone. It may make sense for a large warehouse or office building, but there's 0 point in a home device.
Running unit tests on a third party library? Get real. Either you trust the people who wrote it ran them, or you don't use the library. Do you run the unit tests on every library you download? Have you ever run the unit tests on a library you've downloaded? Hell, unless its all one download they aren't even downloaded, much less run. Welcome to the real world.
Most of the embedded world? The embedded world heavily uses compilers like RVDS. And nobody is going to bother running the unit tests. In addition, its damn hard to write unit tests that test something that should fail in a stack dump.
And if you're writing a library, you don't know what compiler much less what flags the user will use. Are you willing to pay several thousand dollars for seats for obscure compilers?
Because it worked in debug mode (which generally has optimizations off)? Because it was tested on a compiler without this bug? The people writing the memory library is usually not the people writing the app that uses it. Similarly, it was tested on the same compiler, but with different compiler flags? Because that optimization didn't exist in the version of the compiler it was tested on? Because the test app had some code that made the compiler decide not to apply the optimzation? Life is messy. Testing doesn't catch everything.
He meant the amazon.com app that allows you to buy stuff from Amazon, not the Amazon App Store. Amazon.com app is on Google Play and preinstalled on many devices.
Seeing as they're spending 10s of millions on custom content to stream, this isn't very likely. They just decided they didn't want the security risk of opening their data and the engineering headaches it caused for the low amount of value it gave them. Its unlikely it generated them more revenue than it cost.
In fact one of the main reasons to write your logic in mobile in C is that it will run on any platform- then you only have to rewrite your UI layer. But this isn't what they're talking about- they're talking about multiple processors. However Android allows for fat binary apks with multiple versions of libraries, so it isn't that big a deal.
I'm not certain I agree with your argument that most of those a write once, but let's ignore that and pick apart the individual points here/
Locals- maybe, but as those tend to be stack objects making them immutable doesn't matter. Immutability is only a benefit if you're accessing it through 2 threads, which rules out locals.
References- if the object the reference points to isn't immutable, the entire point of doing it to begin with is pretty much lost. Immutable references to mutable objects won't fix any threading issues, so there's no reason to do it.
Hugely disagree with this. Only those objects that need to be immutable should be- forcing creation of new objects is highly inefficient. Yes, it can help around threads, but not as much as its proponents tout, and multithreading isn't necessary for the vast majority of programs. So the default should definitely be mutable.
Making it two keywords with one letter difference between them is completely braindead and sure to make more errors than the feature saves. Imagine if we all used types numf numd numi numl nums for float double int long and short. It would be really easy to miss a 1 letter difference slip in. Its harder to confuse long with short. Now making a new keyword like "immutable" that means no fields of the object can change at all- that might make some sense.
I have a kindle. I don't want it to be anything other than a book replacement. I don't want to input text, annotations (in fact I think ebooks are horrible for anything you would annotate, like a textbook- you need to be able to flip through those), or anything else. I care only about ease of reading the text and battery life (where it excels). If I wanted a tablet, I'd get a tablet.
About the only thing I'd want changed is faster page loading times and better tools for organizing books (list of authors and series, for example) that I've bought.
It doesn't need to be perfect. If cracking it still takes some time, it lowers their resources. And it can still be unbreakable for attackers with fewer resources at their disposal.
True, it's not a problem with the quality of the writing in the book, or of the information in it. It's a problem with it being over-advised to the wrong set of people. If you're an intermediate level of knowledge in architecture or design, it's a good book. If you're a rank beginner having done mostly work on other people's designs, it's going to screw you up. You need to have enough experience to be able to apply it in the right way. That's why I hesitate to put it on a must-read list: because most programmers don't need to read it. It's something that won't help you until a later point in your career than most of the other books on the list.
The problem with that book is that too many people read it the wrong way. Instead of using it as a language to describe design, they attempt to find ways to force their code into patterns or to add patterns because they think they should use them. The result is worse code than if they had never read it. This is especially true of those who read the book before they've seen enough code to understand design. It should be read, but only at the proper time and in the proper way.
No, at this point he shouldn't be giving a flying fuck about languages. He should be studying data structures, algorithms, and learning how to break down problems. Languages don't matter, if you know the other stuff you can pick up whatever language you need in under a week.
CandyCrush is malware, stealing your contact info and selling it to advertisers. A clear case of #1. Simpson's Tapped Out is 2/3. And I would never pay a dime for, or buy any product from a company that makes games where you can pay for an advantage.
First, it requires you to design a game with logical free to play elements. This restricts the nature of games that can be written.
As for charging for games means none would be played- there's a couple of good counterexamples. Nintendo, Sega, Playstation, Xbox. All of the companies that develop for all of those.
I've been a games since I was 5. I'm ok spending 50 or 70 dollars on a good game. I have never once paid a dime for a free to play game, and it's next to impossible to get me to download them- I know they're going to try and nickle and dime me or charge me a fortune if I don't want to slowly grind stuff out (or make it impossible to play parts of the game if I don't pay). And I'm far from the only gamer like that. So they pick up a large number of people who won't ever pay a dime while disenchanting the existing base of people who are known to play video games. That's idiotic.
The remaining devs aren't unethical. Management- the levels I know I wouldn't say are unethical, but their ethics may not be as pro-privacy as yours and mine and I definitely can't speak for higher levels. I tend to believe them that it's a bug, it's an easy type of bug to write- just write some code that tries again in X seconds if it can't get the location, and forget to put any type of exponential backoff in it. But if you have any doubts I'd turn it off since you're already rooted.
I work at startups. They aren't big enough to have directors.
As for large companies and attitude- sure, there's always a few who care. But my experience is 70% don't give a fuck about anything but the paycheck, 25% care only about empire building, and 5% care about the product. This has been consistent through multiple companies. Which is why I don't work for them anymore. You only really see commitment to quality at the small companies.
I really don't want to air all my dirty laundry. I left at the 6 month mark because we agreed to it- I had worked at a previous startup (in a completely different field) bought by the same company and knew I didn't want to be there long term. So we agreed on a compensation package for me to stick around for a few months to get them into a good position, leading the maintenance team as they merged codebases.
I will say very few of the original Swype devs are still there, and some of those that are have moved to other positions in the company. So there was definitely a brain drain. There almost always is when a startup is bought- people were working at a startup for a reason, had they wanted to work for a large company most of them could have easily.
As for the future development of Swype- I have no clue. I talk to friends there, but we don't go over the roadmap together. Especially as I'm potential competition now, working on Dryft (www.dryft.com).
Yes. Read this https://www.facebook.com/notes... Realize that they thought this was a good idea. Facebook's development practices don't particularly impress me.
I did in several of my posts. I haven't been involved with the company in 2 years, and the codebase is now completely different (it got merged with the existing Nuance FlexT9 keyboard, although some of the architecture may have stayed). at the time I worked there there were no location requests, as the feature it's needed for didn't exist yet.
Slashdot Mirror
Mainly so that the owner can monitor it remotely in case of problems. But even then it probably makes more sense to set it once and have it sms maintenance if something goes out of range.
Its a thermostat. When I'm cold, I'll walk over and turn it up. When I'm warm, I'll walk over and turn it down. I don't need it to be internet enabled, and don't want the annoyance of some bug or exploit fiddling with it. Not everything needs to be set from your smartphone. It may make sense for a large warehouse or office building, but there's 0 point in a home device.
Running unit tests on a third party library? Get real. Either you trust the people who wrote it ran them, or you don't use the library. Do you run the unit tests on every library you download? Have you ever run the unit tests on a library you've downloaded? Hell, unless its all one download they aren't even downloaded, much less run. Welcome to the real world.
Most of the embedded world? The embedded world heavily uses compilers like RVDS. And nobody is going to bother running the unit tests. In addition, its damn hard to write unit tests that test something that should fail in a stack dump.
And if you're writing a library, you don't know what compiler much less what flags the user will use. Are you willing to pay several thousand dollars for seats for obscure compilers?
Yeah, you're an idiot.
Because it worked in debug mode (which generally has optimizations off)?
Because it was tested on a compiler without this bug? The people writing the memory library is usually not the people writing the app that uses it.
Similarly, it was tested on the same compiler, but with different compiler flags?
Because that optimization didn't exist in the version of the compiler it was tested on?
Because the test app had some code that made the compiler decide not to apply the optimzation?
Life is messy. Testing doesn't catch everything.
He meant the amazon.com app that allows you to buy stuff from Amazon, not the Amazon App Store. Amazon.com app is on Google Play and preinstalled on many devices.
Seeing as they're spending 10s of millions on custom content to stream, this isn't very likely. They just decided they didn't want the security risk of opening their data and the engineering headaches it caused for the low amount of value it gave them. Its unlikely it generated them more revenue than it cost.
In fact one of the main reasons to write your logic in mobile in C is that it will run on any platform- then you only have to rewrite your UI layer. But this isn't what they're talking about- they're talking about multiple processors. However Android allows for fat binary apks with multiple versions of libraries, so it isn't that big a deal.
I'm not certain I agree with your argument that most of those a write once, but let's ignore that and pick apart the individual points here/
Locals- maybe, but as those tend to be stack objects making them immutable doesn't matter. Immutability is only a benefit if you're accessing it through 2 threads, which rules out locals.
References- if the object the reference points to isn't immutable, the entire point of doing it to begin with is pretty much lost. Immutable references to mutable objects won't fix any threading issues, so there's no reason to do it.
Hugely disagree with this. Only those objects that need to be immutable should be- forcing creation of new objects is highly inefficient. Yes, it can help around threads, but not as much as its proponents tout, and multithreading isn't necessary for the vast majority of programs. So the default should definitely be mutable.
Making it two keywords with one letter difference between them is completely braindead and sure to make more errors than the feature saves. Imagine if we all used types numf numd numi numl nums for float double int long and short. It would be really easy to miss a 1 letter difference slip in. Its harder to confuse long with short. Now making a new keyword like "immutable" that means no fields of the object can change at all- that might make some sense.
I have a kindle. I don't want it to be anything other than a book replacement. I don't want to input text, annotations (in fact I think ebooks are horrible for anything you would annotate, like a textbook- you need to be able to flip through those), or anything else. I care only about ease of reading the text and battery life (where it excels). If I wanted a tablet, I'd get a tablet.
About the only thing I'd want changed is faster page loading times and better tools for organizing books (list of authors and series, for example) that I've bought.
It doesn't need to be perfect. If cracking it still takes some time, it lowers their resources. And it can still be unbreakable for attackers with fewer resources at their disposal.
True, it's not a problem with the quality of the writing in the book, or of the information in it. It's a problem with it being over-advised to the wrong set of people. If you're an intermediate level of knowledge in architecture or design, it's a good book. If you're a rank beginner having done mostly work on other people's designs, it's going to screw you up. You need to have enough experience to be able to apply it in the right way. That's why I hesitate to put it on a must-read list: because most programmers don't need to read it. It's something that won't help you until a later point in your career than most of the other books on the list.
The problem with that book is that too many people read it the wrong way. Instead of using it as a language to describe design, they attempt to find ways to force their code into patterns or to add patterns because they think they should use them. The result is worse code than if they had never read it. This is especially true of those who read the book before they've seen enough code to understand design. It should be read, but only at the proper time and in the proper way.
No they aren't stealing. They paid for the game upfront. There is no theft involved.
No, at this point he shouldn't be giving a flying fuck about languages. He should be studying data structures, algorithms, and learning how to break down problems. Languages don't matter, if you know the other stuff you can pick up whatever language you need in under a week.
CandyCrush is malware, stealing your contact info and selling it to advertisers. A clear case of #1.
Simpson's Tapped Out is 2/3. And I would never pay a dime for, or buy any product from a company that makes games where you can pay for an advantage.
First, it requires you to design a game with logical free to play elements. This restricts the nature of games that can be written.
As for charging for games means none would be played- there's a couple of good counterexamples. Nintendo, Sega, Playstation, Xbox. All of the companies that develop for all of those.
I've been a games since I was 5. I'm ok spending 50 or 70 dollars on a good game. I have never once paid a dime for a free to play game, and it's next to impossible to get me to download them- I know they're going to try and nickle and dime me or charge me a fortune if I don't want to slowly grind stuff out (or make it impossible to play parts of the game if I don't pay). And I'm far from the only gamer like that. So they pick up a large number of people who won't ever pay a dime while disenchanting the existing base of people who are known to play video games. That's idiotic.
The remaining devs aren't unethical. Management- the levels I know I wouldn't say are unethical, but their ethics may not be as pro-privacy as yours and mine and I definitely can't speak for higher levels. I tend to believe them that it's a bug, it's an easy type of bug to write- just write some code that tries again in X seconds if it can't get the location, and forget to put any type of exponential backoff in it. But if you have any doubts I'd turn it off since you're already rooted.
I work at startups. They aren't big enough to have directors.
As for large companies and attitude- sure, there's always a few who care. But my experience is 70% don't give a fuck about anything but the paycheck, 25% care only about empire building, and 5% care about the product. This has been consistent through multiple companies. Which is why I don't work for them anymore. You only really see commitment to quality at the small companies.
I really don't want to air all my dirty laundry. I left at the 6 month mark because we agreed to it- I had worked at a previous startup (in a completely different field) bought by the same company and knew I didn't want to be there long term. So we agreed on a compensation package for me to stick around for a few months to get them into a good position, leading the maintenance team as they merged codebases.
I will say very few of the original Swype devs are still there, and some of those that are have moved to other positions in the company. So there was definitely a brain drain. There almost always is when a startup is bought- people were working at a startup for a reason, had they wanted to work for a large company most of them could have easily.
As for the future development of Swype- I have no clue. I talk to friends there, but we don't go over the roadmap together. Especially as I'm potential competition now, working on Dryft (www.dryft.com).
Yes. Read this https://www.facebook.com/notes... Realize that they thought this was a good idea. Facebook's development practices don't particularly impress me.
I did in several of my posts. I haven't been involved with the company in 2 years, and the codebase is now completely different (it got merged with the existing Nuance FlexT9 keyboard, although some of the architecture may have stayed). at the time I worked there there were no location requests, as the feature it's needed for didn't exist yet.