HN user
This is great -- I hate having compiler/runtime advances in Mac OS X always tied to the latest platform release. It can take years before your customer base upgrades, leaving you unable to leverage what I'd consider basic language features -- like fast enumeration, or now, closures.
I'd be curious to hear the reasoning of the users who 'upvote' Jeff Atwood articles such as this one.
The subject matter is interesting, but what I find most interesting is a blog performing real, 'hard-hitting' local journalism, of genuine interest to a very specific social subgroup.
Keep money per answer out of this. It's amazing what happens when you keep a site like SO working on social norms and avoiding market norms.
Other than money, how do you prevent an expert-exodus as expert users are deluged with simpleton questions? Amidst a deluge of bad questions, there's little value to remain active, as your own questions can rarely be answered, and users aren't providing interesting questions.
Something else is needed to provide a substitute for that value.
Alternatively, you must prevent the exodus by filtering the kinds of interactions/questions that occur. Mailing lists, for instance, have a barrier to entry to serve as a first-pass filter (the subscription), and then a community to enforce community norms.
On the other hand, Stack Overflow is racing to the bottom, so to speak, on the quality of questions and the people answering them.
Either way, money is what would entice me to answer questions on the web. Currently I do it for free on IRC, but only because standing community helps ensure that the quality of questions is reasonable on the channels I frequent.
How much money would make it worth your time? If your expertise is too high / too esoteric for the StackOverflow community, then you should command high prices in the marketplace.
$5-$15 per answer would be reasonable given the limited time involvement.
It's doubtful to me that you could appeal to expert users to exchange time for money when it is better leveraged by consulting and entrepreneurship.
I seem to have enough free time to blow a fair portion of it commenting on Hacker News.
Until I clicked on the link, I was excited, as the comments on monetization lead me think they might be providing a marketplace for me to provide for-fee answers to users.
Unfortunately, this is not the case.
As it is, I don't bother to use StackOverflow. My questions would be too esoteric for the audience/format, and nearly all of the questions I see are boring, easily answerable with a search of the documentation. The questions would be less boring if I were paid to answer them, and then I'd be more likely to find a few gems to answer, too.
If this fable didn't hint at that, what was its point?
That convincing management regardless of your productive output is what matters at the end of the day? Perhaps at some organizations, but it's not a particularly accurate, nuanced world view.
I doubt this story would be conveyed in reverse -- the stereotypical "rockstar hacker" produces vast reams of code that will fail catastrophically, but comes out ahead by, upon 'completion', immediately pushing responsibility for the disastrously buggy code to the "stodgy" enterprise engineers who get called in to maintain the project. The "rockstar" moves on to the next project, where he'll repeat this performance, and the stodgy developers get poor performance reviews.
No, because an "anecdote", by definition, is not statistically relevant.
"Enterprise teams" are not, inherently, profoundly stupid in their practice of software engineering, and not all "hackers" inherently produce worthwhile, quality code.
This completely fabricated fable of software engineering is a simple straw man argument, and I've flagged it accordingly.
It's fairly easy to degenerate "enterprise developers" when you're defining what "enterprise" means.
I'm sorry but are you kidding here? You think a web developer who already has experience in all the tools used to create a web app is going to spend the equivalent amount of time learning a completely new languange, platform, developer tools et al AND THEN using them to program an app. I'm sorry but that's really a ridiculous thing to say.
As a software developer, Objective-C is just another imperative C-derived language (a pure superset of C, actually), with Smalltalk-decedent OO features. It's not (or shouldn't be) an alien experience.
My comment assumed a baseline software developer proficiency. If simple high-level webapp development is all you've ever done, then of course -- writing an Objective-C application will be more difficult. Perhaps that's a good reason to write one.
As for the rest of your argument,AT&T's Edge connection downloads at around 25KB. So a 1K page (which you claim causes an "unpleasant wait") would download in 1/25th of a second even on a slow connection.
In addition to failing to account for additional resources (the page won't be 1K in total), you forgot to account for latency (there's quite a bit).
As for the rest, my point still stands. Everything you spoke of requires a cracked iPhone which the great majority of people don't have anyway.
Nothing I've mentioned requires a jailbroken phone for any purpose.
It's actually not that good a point. Using JQuery you can get a web app as low as 1k so slow connection isn't that big a problem.
1k is still a pretty unpleasant wait when you're looking for 'instant', and unfortunately, if I exit Safari to use another app (which I often will), Safari will very likely need to reload that page.
Web apps can integrate into most of the iPhone's features like contacts (notable exceptions being location and camera).
Web applications can't integrate with the address book, actually.
The other stuff he mentions like p2p, mDNS, etc... are very specialized applications that to the best of my knowledge only work on unlocked iPhones (I could be wrong though I know bit torrent has been banned from the app store)
The P2P I was referring to is WiFi/Bluetooth zero-configuration phone-to-phone 'networking', for magically connecting applications on two or more phones. It's pretty neat.
A web app is never going to work for edge case style applications but for the majority of web sites it's probably a good idea just to spend a day customizing their site for an iPhone (I've become fond of iWebkit: http://iwebkit.net/) rather than buying a mac, learning objective-c, etc...
I really don't think they should be considered 'edge cases'. There are so many ways that the user experience is better via integration opportunities, speed, and native look and feel, that I don't think anyone should consider a mobile webapp to be a viable replacement.
Webapps are a reasonable substitute assuming nothing else is available and you can't afford to produce a proper application, but I'm not convinced that you'll spend more time and money producing a native app than you'd spend producing an equivalently high-quality webapp alternative.
As an iPhone user, I strongly prefer native applications. They can integrate with the built-in technologies (address book, location, P2P, MDNS, etc), and they don't simply stop working for 30 minutes while I ride the subway.
I'm familiar with game development. I make games for the iPhone in my spare time and I make more money than I ever have in my life, and my apps aren't even popular compared to things like Ocarina or Tweetie or Pocket God.
I'm truly, genuinely surprised, as most indie game developers I know have been lucky to recoup their costs, and fewer have seen any sustained revenue to speak of. Some got lucky, most have not.
What games do you develop, if you don't mind shedding the mask of anonymity? (I understand if not, I'm anonymous here because it allows me to actually speak freely).
At this date in time, I am the model for an iPhone business. A single guy making indie games. It might morph into something different in the future. I imagine there will be a separate path for business applications. Perhaps $30 CRM apps will be sellable in a bundle with enterprise software to large companies. But I don't think end users will ever pay $30 for iPhone apps except for very niche cases. Most people view their phone as an entertainment device, apps are on the same level as ringtones. The market may correct itself by flushing out all the players who can't make a profit on a $1.99 game, but it's not going to correct itself by suddenly having mostly $30 apps on the app store.
Maybe you're right, but I hope not. I'd be curious how you can afford rent on $1.99 game sales, what sort of revenue "more money than I ever have in my life" means, and whether you've seen more than one of your released applications succeed.
If you really care, use a real standards-comformant address parser, most languages have at least one -- Java does. Otherwise you're just wasting your time, and the time of any users you hose with your amateur-hour validation.
I seriously doubt that will happen. People have stopped buying $30 software for their computer, why would they buy it for their phone?
Do you have statistics on that? My wife just bought Balsamiq for her computer without blinking, and that was $79.
Anecdotally, I know quite a few indie and larger commercial developers paying their salary and more on $30+ desktop software. I know that Balsamiq sure isn't hurting.
It's primarily the webset that can afford to subsidize free product on the back of VC.
The iPhone is a platform for cheap apps, mostly entertainment related and games.
Games (even small ones) take a surprising amount of resources to create, from art assets to developer time. Unless your game is a lucky iPhone hit, you just can't cover development costs.
If you want to make a go at an iPhone business, you optimize around that fact. You don't try to drag your existing business model to the iPhone and hope that the market drastically changes.
If your existing business model is "pay the rent", much less "cover payroll", then yes, you're quite right -- you can't drag your existing business model to the iPhone.
We do bespoke development for iPhone customers. They lose money, we make payroll, and we wait for the market to mature. Until it does, the iPhone is a total wash, and don't be surprised when the smaller shops that can't eat the loss start dropping out. It's a gold rush.
$1.99 is less than the cost of a movie rental, but movies have massive leverage across an incredibly large market. This idea that software should only cost $1.99 is remarkably poisonous, but fortunately, the market will correct that.
If that's the case, then the market is unsustainable. Players will fail, causing scarcity, raising the value of applications, and conditioning users to expect to pay more.
Unless you produce one of the very few 'hits', you'll lose money developing a $1.99 application.
I think their price is more-or-less reasonable in terms of the value provided and in comparison to application pricing for other mobile platforms:
http://www.berryreview.com/2008/04/22/review-calculator-apps...
http://www.berryreview.com/2008/07/31/calculator-apps-part-5...
iPhone application prices are unsustainably low. I find the $30 price point to be a very encouraging sign.
Given that conforming with the standard is effectively free, do you have any other justification for your non-conformal position of "I'd say 64 is enough. Anything above is just weird"?
Willfully and capriciously ignoring standard requirements that you think are "weird" results in non-conformal implementations that confound users and other developers attempting to interoperate with your systems. I'm genuinely surprised to be writing a paragraph defending standards conformance -- I'd have thought that this position was basic common sense among software developers.
I'm surprised (and confused) -- can you really include a great number of large, verbatim or nearly verbatim blocks of text from Wikipedia, cite them, and not be called out for plagiarism?
What's to stop any author from saving themselves hours/weeks/years of effort by simply by copying text and sticking a citation at the end of the paragraph, as it appears was done in this case?
You can empirically determine exactly what's in an opaque set of anything (NSArray's various public access methods) and exactly what part of the area of a view is covered by a subview.
The facilities necessary to modify the hierarchy are defined.
The content of that hierarchy is undocumented and may change at any time. The behavior of modifying the opaque view hierarchy is undefined.
You can do this at run time for any UIView, even those which are part of so-called opaque types. Those methods are documented, and you can read about them above. I'm done trying to tell you that.
The contents are undocumented. You can not assume any behavior whatsoever if you modify the contents of the entirely undocumented view hierarchy.
Having been in the position of dealing with customers foolishly relying on internal implementation details, you honestly make me want to beat my head against the wall. It's one thing to make the mistake, it's another to proudly celebrate it.
I can't imagine how frustrating your iphone app development experience must be if you rule out experimentation of all types. How did you ever get past the code-signing step?
You still misunderstand. It's simple: you can not firmly rely upon undocumented, empirically-derived knowledge without a vendor documented invariant.
The contents of an opaque view hierarchy -- and its behavior if modified -- are entirely undocumented.
My capacity for civil dialog is exceeded, and I'll stop here.
This is exactly what I said above. If you expect a certain structure, your app will almost certainly, and is defective. However, you can rely on the fact that the UIView hierarchy can always be modified, regardless of what's inside (or not inside) it. Because that fact is documented.
No, you can not rely on that undocumented assumption:
1) You can not know what to modify in an opaque set of views, because the contents of that opaque view hierarchy is undocumented.
2) You can not know that it is safe to modify the opaque view hierarchy, as doing so may break the undocumented invariants of the opaque view hierarchy.
3) You can not assume that the members of the view hierarchy meet your assumptions regarding structure, subclass, or nature, as the view hierarchy is opaque and not subject to declared API invariants.
If it's not documented, it is not a defined invariant, and it can not be assumed.
To claim otherwise is to simply fail to understand the purpose of defined invariants. Software development is no place to rely upon empirically-derived knowledge.
You're wrong. You don't have to use a single method or class that is undocumented to add or remove stuff to the camera control's UI.
No. You do everyone reading a remarkable disservice. The UIView hierarchy itself is undocumented. The contents and ordering thereof are undefined, may change at any future date, and can not be relied upon. The application did, in fact, break when the OS was upgraded.
Apple's use of "Private or Unpublished API" isn't intended to leave room for semantic arguments about the true meaning of "private", "unpublished", or "API", and they've clearly applied the standard industry definition in this particular instance.
But platform makers make changes that break apps all the time; why should this guy get his app banned forever?
Apple guarantees that their published, documented behavior (eg, API) will work across releases, and they strive to meet this guarantee. Where they fail they assume responsibility for fixing the issue -- file a bug.
Unlike the usual arbitrary, capricious, and infuriating appstore rejections, _the developer deserved this._
In order to implement something like Quick Shot, you have to muck around in the undocumented innards (private API) of the Apple-provided camera view widget. This is clearly forbidden by the developer agreement, and will easily result in your application breaking across minor and major releases. This breakage is evidenced by Jared Brown having to submit a new update for 3.0.
I take umbrage with his characterization of Apple leaving his users in the lurch. This is incorrect. Apple's minor culpability is only in choosing to not provide a better camera API.
Knowingly selling a product that clearly violates the developer agreement and will break in the near future is dishonest. The product is defective. I have sharp words for the App Store, and Apple's ridiculously arbitrary revue process, however, in this case the developer is clearly in the wrong.
That was not my experience, but you and I probably have differing opinions of "detrimental", and I'm not sure how you would correlate abuse or "community detriment" with your data.
We tend to be patient with individuals (even semi-abusive ones) before resorting to crude methods such as banning.
No, I regularly find modern registration forms that won't accept mailinator or even hotmail addresses (and your service is probably more akin to mailinator than hotmail).
I experimented with it and racked up 400 megabytes in data transfered without even trying (Checked e-mail, visited some web pages).
If AT&T then charges me 0.60/megabyte as stated in the Youtube comment, I'm looking at a pretty hefty bill this month.
I hope it's not due to the negative tone of the article and comments, coupled with scribd being a YC company -- I believe flags are administrator-reviewed.
Just to make sure I'm not crazy, I found another 100+ page book and downloaded the PDF just now. No requirement to upload any files.
Perhaps you didn't meet the criteria to trigger this behavior, you are not a member of the A/B group that was shown this UI, etc.
Doesn't anyone fact check stories before posting their comment rage?
The story is sourced, and veracity is riding on the source's reputation (and vis versa):