Your broker cannot offer an app with IAP that does purchases of goods or services that cannot be used in the app itself. (iOS Developer Agreement, schedule 2:1.1)
This is all about IAP. If you aren't allowed to offer IAP for your particular item, these rules don't apply. If, however, you could theoretically use IAP for your content, you cannot offer such a service solely through external purchases.
We'll see. Your logic was impeccable a year ago, before any iPads were sold; that's probably why iBooks is such an also-ran today. (Contracts take time to run out, the iPad isn't even a year old, and its success has taken even the optimists by surprise.)
But ignoring the iOS market gets harder by the day. There's a lot of tasty, tasty customers out there.
We'll see what happens. Note that Apple's new, um, clarification of its policy doesn't take effect for several months. I expect there will be weeks of furious behind-the-scenes jockeying for position among Apple, Amazon, and various publishers, after which there might be more announcements.
The thing is, publishers and distributors can make better deals with Amazon, because Amazon will carry a wider array of stuff including physical books, including books that don't make sense as ebooks such as pop-up books, or the books that come with accessories like tree seedlings to plant or meditation beads or whatnot.
He gives one example, of an SEC investigator who got fired just for trying to talk to John Mack, now running Morgan Stanley, about a suspected case of insider trading. (An associate of Mack suddenly started buying a company's stock in huge amounts, shortly before the company was acquired, and made $15 million. The acquired company had been a client of Credit Suisse. John Mack interviewed at Credit Suisse just before this, and had been leaning on his associate for a piece of another deal. The implication being that Mack picked up some info at Credit Suisse about the upcoming acquisition, passed it to his buddy, in exchange for a piece of the other deal, which I think made Mack about $10 million.)
Morgan Stanley had a bunch of their lawyers pressuring the SEC above the investigator's head. Most of those Morgan Stanley lawyers were former SEC or DOJ bigwigs themselves. As a result, the investigator was fired, even though he had recently received sterling reviews. The fired guy eventually won a $750k wrongful dismissal suit against the SEC.
With all respect, this is absolutely small fry in the scheme of things. Insider trading goes on all the time, irrespective of market conditions. Insider trading did not cause the financial collapse. This type of story is likely to happen in any decade you care to mention, and is not indicative of the wider culture of taking big bets based on other people's money, and getting richly rewarded for it.
No, but it is an indication of the "enforcement" and regulation bodies being cowed and coopted by the bankers, which certainly effects the handling of the recent clusterfuck by the same bodies.
If they aren't going to let an investigator bring John Mack in to talk about a little insider trading case, they certainly aren't going to bring him and his peers in to talk about melting down the financial system, unless their message is "can we throw any more free money at you?"
I agree with you here, but this doesn't detract from my main original point. All of the things which caused the problem were totally legal at the time they were done. So while side-issues like this are criminal and deserve to be punished, the actual things that caused the problems were completely legal. The Sec investigators couldn't prosecute for melting down the financial system, because it was being done within the law. The law was (and is) wrong, but that doesn't make most people on 'Wall St' criminals.
Among all the things wrong with the financial system, insider trading is arguably the least important. The publicly known conflicts of interests should be alarming all in themselves.
Auto theft goes on all the time, but if a car that was reported stolen on Monday showed up in my driveway on Tuesday, and a cop showed up to ask me a few questions, I wouldn’t be able to get him fired.
Good point, the fact that he went to a 4th level boss above the agent is telling. When a trader has a direct line to the top of the SEC, there is a real problem.
I think a lot of the benefits of OO reuse have been lost due to platform shifts. If you build a system on NeXTSTEP in the early 90s, then throw it out and switch to Java, then throw it out and switch to C#, you're naturally going to lose a lot of the efficiencies you theoretically could have taken advantage of had you somehow managed to stay on NeXTSTEP or OpenStep all along.
And then, of course, you have mergers and acquisitions leading to code being thrown away or warehoused or merged with other systems, or new management deciding to start from scratch.
Basically, the industry doesn't really have a long enough attention span to really make the most of OO code reuse.
People have long talked about how OO failed to generate code reuse, but I don't understand how they do it with a straight face. You reuse masses of OO code every time you write a non-trivial program using a modern standard library.
I think the people making this criticism are looking in the wrong place for the reuse, and / or had weird ideas of what could be reused, and how it could be reused, to begin with.
The reuse that OO gives us comes from raising the level of abstraction with which the program is written, in particular because runtime libraries are so much larger ("batteries included", etc.). The hierarchical namespaces and encapsulated structure of modern class libraries reduces their cognitive overhead. For example, in .NET, you can work with WebRequest, TcpClient or Socket, depending on what level of control you need; and the conventions for working with these things are pretty uniform across the board. Larger applications are self-similarly written at a higher level, reusing code within themselves in a framework-like way.
But the people who thought there was going to be some kind of central library of domain-specific classes in your company, that you would reuse in multiple disparate applications, I think that was always fairly naive; reuse implies coupling, and coupling of things that are individually subject to change in ways that affects their users is fraught with problems, and always has been.
The best candidates for reuse aren't usually representations of the domain concepts that are central to a business, because each application in the business will probably be wanting to do something quite unique with those domain classes. Rather, it's concepts that are self-contained, universal, not likely to change much over time nor need different intrinsic behaviour from application to application, which are best suited to reuse.
The biggest problem with OO is the abuses. I recently worked with a large codebase where /none/ of the behaviour for objects was in the objects themselves. Some Architect had come along and beaten it out of them with an extreme application of the 'too many patterns' anti-pattern.
One way they justify this is to 'reduce coupling', and so your comment about coupling tripped a red flag for me. Whenever I want to take the piss out of an Architect I just tell them that we should 'add an extra layer of indirection' to the design. 99% of the time they agree without realising that I'm satirising them.
"where /none/ of the behaviour for objects was in the objects themselves"
Actually, this could be a good thing, depending on what the goals were. For example, non-member non-friend classes are often more OO than putting everything into the class[1]. Furthermore, if you want to use function overloading for multiple dispatch, the keeping the functions separate from the objects is also useful. If your system is highly concurrent, keeping the code and data separate can be quite helpful. Also keeping data in structure-of-arrays form and using external functions to operate on these arrays can make huge differences in terms of cache usage, potential parallelism and vectorization of instructions.
Coupling might be a reason to do this, but its certainly not the first reason I think of. There are plenty of better reasons (and as always, not all reasons apply to all codebases).
TL;DR: There are lots of reasons why doing this could be a good thing.
(fwiw, I like to do this with my core data structures because I believe code and data should be kept separate (and that data is the more important of the two). I do like to provide normal objects as an API though, because I often feel that its a natural interface, but the internals of my code are rarely very OO in the C++/Java sense).
"But the people who thought there was going to be some kind of central library of domain-specific classes in your company, that you would reuse in multiple disparate applications, I think that was always fairly naive"
Well, perhaps, but I've seen it done successfully in NeXTSTEP/OpenStep shops back in the day, such as an investment bank. Not one big library, but a few frameworks so there's some separation.
The team I was on had our own frameworks, shared among the apps we developed. We also used/built our frameworks on frameworks from the bank's Architecture group, which were also used by other development groups.
NSFormatters do a lot of stuff, internationalization, user preferences for number representation, etc. It shouldn't be a surprise if they're a bit heavy. IIRC they're pretty much intended for UI display, not for tight loops.
"A single use of an obj-C number formatter..." [emphasis mine]. Carmack is a pretty smart guy, he wouldn't be using number formatters in an inner loop.
Anyway my point was that you can find fault in just about anything. But, you'll be much better off if you found out the strengths of each language instead, and used that to your advantage. Here's a guy that has this figured out: http://www.savoysoftware.com/blog/my-iphone-is-not-a-mac-pro...
We need fewer religious language BS articles like this one, especially from a guy who seems completely clueless about C++.
Well, no, it isn't. Many things are notable that are not "popular", or even common. Leprosy, flesh-eating bacteria, progeria, Jeffrey Dahmer.
There's also a vicious cycle here: the existence of an article on Wikipedia may lead people to not post related articles elsewhere on the web, instead relying on the WP article. That may lead in turn to the article's subject being considered insufficiently notable.
You measure it by counting how often people write about it in certain contexts. That seem to be "related" to popularity to me, but if you don't think so, that's fine, go your own way with my blessing.
Then they went off to Wall Street and collected their millions of dollars.