Comment Re:Not to worry (Score 1, Funny) 62
Thank you for the response with the exact level of pedanticness I would have gone for personally. You saved me some time.
Thank you for the response with the exact level of pedanticness I would have gone for personally. You saved me some time.
This is just he exception that proves the rule.
It's when you find TWO exceptions, that you should start to worry about the rule itself...
How does Apple "monetize" its userbase information right now?
It doesn't, because it doesn't need to (see: Stock Price, cash on hand).
Why does Apple feel the compulsion to plow money into an inferior map service?
Apple maps are superior to Google Maps at this point. They are more readable for one thing (true from the outset) but also I have noticed more errors lately in Google Maps than Apple Maps (and Google Maps always had errors to begin with).
The reason Apple continues forward is because that way they do not have to worry about how users are monetized by other map providers... which you are if you use Google Maps.
Originally said:
Stock valuations are based not only on actual assets, but future growth and earnings potential.
You replied:
They're comparing the stock valuation to what the company would sell for if purchased. When you sell a company, you're also selling the "good will" and other value inertia things like brand familiarity
Goodwill is ALSO something that can increase in the future, just like monetary assets - you buy stock with the idea that the entire company value (including goodwill) will grow. So the original point is still a sound one.
Clinton did not selectively keep emails she thought were state-department related - she came up with a small list of keywords she thought would match state-departmnent matters and deleted ANYTHING THAT DID NOT MATCH.
So basically her keeping state department related emails is only as true as her ability to come up with keywords that matched everything she did over years of service...
Not to worry though, the Chinese and many other foreign governments have a full backup, which they have pinky-sweared not to use as leverage should Clinton be elected president.
I totally agree that ad-blockers are immoral. Realistically how can you support denying a web site ad revenue which is the only reason it can continue to exist?
However, just as immoral are the way ads are tending to be presented now. Full screen ads as noted, or un-avoidable popovers are to my mind a betrayal from the other direction - a web site needs revenue to survive, but that should not come at the expense of the sanity of the reader.
My solution is to simply sop using a site if I find the ads grow too obnoxious. But I also really can't see anything morally wrong with blocking ads from a web site that has gone too far in embracing abusive ads, almost as a form of punishment...
At one point we needed the government just to reach space.
That time has passed. What we need now is not one gatekeeper to bring us into space, but the gates to be flung open. NASA still has uses but the majority of space travel and research going forward should be done by the people outside the government, the people who from time immemorial have been always able to do something hard and dangerous and expensive and make it better and faster a cheaper and more accessible to everyone.
Do you want to visit space? I do. I know that would never happen just having NASA around, just as I know it will be feasible giving some of NASA's money to SpaceX and its ilk to refine and commoditize space travel.
So Snowden is going to be pardoned by Obama now, right?
If by "pardoned", you mean "Drone Strike", then yes, Snowden will be "pardoned".
Out of four garden lamps I put in about five years ago, only one functions and that very poorly.
The LED lights themselves may still work, but the solar collectors on top get clouded or dirty (or both) and stop providing power.
The recommended break point is as it is with any language - whatever is most readable.
Sometimes that might be the return value being on the next line.
Sometimes it might be each parameter on it's own line.
I myself prefer to either have the whole thing on one line, or everything broken out per line if that will not fit. But I'll admit I let some longer methods sometimes wrap to two lines on the display (even though it's really one long line).
The second is for the return value, yes.
Although you can absolutely name the return values something different, I just had in mind some optional transformative thing where you could use it or not and treat the data tuple the same way.
I've done Objective-C since before the release of the iOS App Store, and Swift almost full time since Apple released it last year...
Some of the things you mention beginners do not have to use (generics, and struts for example). To keep things simple to start with, they could just use classes instead.
I will agree that optionals might be a bit rough on the beginner - but perhaps not as starting from nothing, the concept of a bucket that holds a value instead of just using the value directly, would not be so foreign...
You also mention different ways to specify params, and shortcuts - but I see those as a major plus. You can just pick a level of detail that makes sense to you and work with that, until you feel comfortable with reducing further the syntax you use.
I think the function syntax is one of the cleanest and easiest styles to understand... I believe a few other languages have this form also, but in swift you just say something like "a function named takes in these params, and outputs those params" So it looks like:
func myFunc (a:String, b:Int) -> (a:String, b:Int)
it's just so balanced that you can have any number of things in or out.
There are a few things I think make Objective-C less approachable.
The separate header files, and the heavy modern use of private categories to define most internal properties confuse people as to where they need to define things.
Simply more verbose syntax all over. I like verbosity myself, I love named parameters... you get that with Swift though with a lot fewer characters typing.
Part of that extra syntax in ObjC is the shorthand to make arrays like @[] and @(value) to make NSNumbers... but in Swift Integer is treated the same as String, both are first class objects that you can do things with so it's more consistent. That in particular is I think a large benefit for newcomers.
Wrapping it in foil means it won't function as anything.
But it also means the work application will not record any downtime for the app running.
If you are "on call" then you are technically working, so that phone needs to be 100% functional and they have the right to track it.
True enough (I totally agree the company as the right to track their own equipment) but if a boss said something creepy like "I can see how fast you are driving" in the bag it would go when I was driving anywhere and I'd just blame bad cell reception on the dropoff... I could pull it out every 15 min or so to see if there were any messages. But it would technically be dereliction of being on-duty...
It is important to note, however, that putting the phone in the Faraday bag emulated loss of signal, instead of loss of power,
I was mulling that over after I posted, but after some thought I think that ends up being OK also as it's easy enough to claim your car blocks cellular signals really well or just were in a bad area... at any rate the app wouldn't show it had been shut down which I think would be the main trigger they would get onto you about.
That's a great point but it does seem like a company should have the right to enable GPS tracking for company assets. Perhaps a good compromise would be that you could indicate when you were off-work to avoid tracking, but if required the device could be signaled to turn back on tracking.
I personally would probably get one of those signal shielding bags and drop it in there when I wasn't to be on-call. Then you could carry it with you even. Then it also appears just as if it lost power for a while, so it would be hard to get in trouble over it...
Variables don't; constants aren't.