Identifying Arbitrage Opportunities with Graphs - <AUTHOR> http://gist.neo4j.org/?7331087

<comment><USER2> Besides the fact that you don't take into accunt the spread (the buy / sell prices, which are never equal), the big risk associated with this kind of 'arbitrage' is the fact that the transactions won't occur simultaneously. What happens if during the sequence of this 'arbitrage' prices move enough to offset the potential gain ?

<comment><USER3> Doesn't take into account the fact that FX is "last look" for the provider of the liquidity and so any one of the transactions along the way could be rejected. In fact even if the trade wasn't rejected at the time of transaction, the liquidity provider could come back later and request a particular trade be reversed or manually adjusted as it was unprofitable for the liquidity provider.

Also doesn't take into account that in FX specifically, arbitraging is heavily frowned upon and if you are caught you are likely to have your account closed down.

The reasons for both of the above is that unlike for commodities/equity/futures/etc which are traded on a market, FX is more like a "gentleman's wild west" ie no defined market rules, but a lot of unofficial gentlemans agreements in place about what you can and can't do.

Various exchanges have tried to offer a standardised FX product and they all have the same issue - because a transaction on an exchange doesn't allow "last look" provision and the market makers _have_ to honor the transaction, once an arbitrager infiltrates the market the market makers are basically at the mercy of the exchange (and all the latencies and rules within) and are forced to widen their spreads to the point that it no longer an attractive marketplace for all other market takers.

Having said that, arbitragers still do exist in FX. The most (in)famous one in Japan is a guy "Arb-san" who was making a motza in the countryside in Gifu. He had a great blog where he uploaded photos of his cars and piles of cash and trading rig, and commentary of how he was sticking it to the dumb banks. Unfortunately I can't find this blog anymore, but I did manage to find a profile of someone with the same name online that has some cars that I recognise from the that blog:

[http://minkara.carview.co.jp/en/userid/1956440/car/](http://minkara.carview.co.jp/en/userid/1956440/car/)

<comment><USER4> Can you explain the rational behind arbitrage being heavily frowned upon? Either arbitrage is effective, and prices are set efficiently without any intervention, or they aren't and the exchange makes collects their fees for the trades.

<comment><USER3> Essentially the assumption that prices are set efficiently does not hold for FX. Errors in pricing can occur, and when there is an arbitrage opportunity and a market maker loses money then it is assumed (possibly) due to a pricing error which the arbitrager shouldn't have taken advantage of.

A bit of history how the messaging protocol works might make things clearer.

In the old days a trade would take place over the phone as follows:

You: "I'd like to buy USDJPY, $1 million worth please" Market Maker or broker (MM): "Ok you can get $1 million dollars worth for 123"

At this point there was a gentleman's agreement you would respond within 4 seconds whether you want that price or not (as the market may move)

You: "Mine, I'll take it"

Here you have completed your side of the contract and cannot back out. You just need the MM to confirm that they can still get your USDJPY 1 million 123 (this was traditionally confirmed with a trader sitting nearby who could see all the prices and volumes being published in the market and could give a price at which they could hedge the entire volume and still make a profit. These days traders still perform this role to a small extent but generally the broker would read a price off a screen themselves).

If they can, MM: "It's yours, USDJPY 1 million at 123" and the transaction (contract) is confirmed good. The position is transferred to you, and the trader who provided the original price hedges the risk and gets out of the position, flattening his trading book.

If the market has since moved and the trade is no longer profitable, MM: "I'm sorry the price has changed, you can now buy at 123.1" and you jump back up to the previous

Ok, so all this has been upgraded with technology over the years, specifically messaging is now done via the FIX protocol (same as is used for other asset classes). But the basic flow is still the same:

You: Request price at a quantity MM: provides price You: decide whether to take that price MM: confirms that the price is still good, then sends you confirmation the trade was good (and hedges the trade), or otherwise rejects the trade.

The issue arbitraging causes is that if the prices in the market move and those moves are known to the arbitrageur but not to the market maker then the market maker gets into a position where they accept and confirm the trade, but can't hedge out at the price they thought they could, and so lose money on the trade. A few of these trades and the losses start to build up, and if it keeps happening with a certain client (remember, no anonymous exchanges here) then it's easy to punish that client (show them worse prices, cut them off completely, etc). If an arbitrageur is hiding behind a third party then the market maker might have enough clout to punish the entire third party (in which case it would be in the third party's interest to seek out the arbitrageur and punish them themselves).

</comment></comment></comment></comment><comment><USER5> This doesn't take into account available volume. For that you need to solve a min-cost flow algorithm, using for instance the Ford–Fulkerson algorithm.

<comment><USER6> Available volume? Forex is the most liquid market in the world.

<comment><USER7> Yes. But if your arbitrage pattern is only 3 pips profitable, and you are exchanging millions at once, you might expect that the amount of available orders matching your path may actually matter.

</comment></comment></comment><comment><USER8> I'm assuming one would have to manage a hedge fund to actually be benefited?

Seems somewhat unfeasible for an individual investor.

<comment><USER9> Well, hedge-funds don't play arbitrage games anyways. This is for scalpers and mostly day-traders. Banks don't even really play arbitrage - not as a means to profit at least.

Only benefit to being a hedge-fund is you have lots of money to play with, which you'll need because the profits in arbitrage are very thin. You need likely 20K+, good spreads, fast execution, and an automated strategy to consider it worth your time.

<comment><USER10> Hedge funds make insane amounts of money using arbitrage strategies.

</comment></comment></comment><comment><USER11> You know it is a recent snippet because it mentions currencies that havent been in use for over a decade..

<comment><USER12> Bringing it up to date must be one of those exercises for the reader.

</comment></comment><comment><USER13> been using neo4j lately and loving it.</comment>


Goog Analytics question - <AUTHOR>

I have a site with many user generated pages. Should I embed the analytics code in every page on the site, or just select few? <comment><USER2> I guess I don't really understand the question. My first thought was "Just put the code in your footer in your template(s) so that it is on every page". Isn't that how it's done? Perhaps I'm being a bit naive; my understanding of GA is definitely not great.

</comment><comment><USER3> Short answer: If you want metrics to include those pages - yeah.

Long answer: By user generated pages, do you mean pages over which the user has ownership e.g. blog posts? If so, it might be more polite to analyze server logs. Otherwise, yeah.</comment>


The One Thing Every Software Engineer Should Know - <AUTHOR> http://www.codinghorror.com/blog/archives/001177.html

<comment><USER2> The title made me think about what my answer would be. If there's one thing a programmer should know, what is it? What is the most important thing I didn't understand about programming when I started doing it?

My answer would be: that code should be seen not as a static thing, like the answer to a math problem, but as an evolving effort to figure out the right question to be the answer to; and that it should thus be written to be easy to change.

<comment><USER3> Coming up with "The" one thing a programmer should know seems too narrow a question. Kind of like "What is your favorite song?" instead of "What are some of your favorite songs?" A more interesting question might be "What things would you emphasize to someone learning to program?" Flexibility? Precision? My answer:

Every programmer should

1\. Learn C / Assembly - Understand how code interacts with hardware.

2\. Learn Lisp - Understand how ideas interact with code (and vice versa).

3\. Learn "O" notation - Understand algorithm complexity.

4\. Be clean and flexible.

<comment><USER4> 5\. Write unit tests.

6\. Refactor mercilessly.

<comment><USER5> 7\. sleep

8\. goto 1

</comment></comment></comment></comment><comment><USER6> This is true of many industries. I have a friend who is a wonderful painter. People who see his work tend to think highly of it. Problem is, he only knows people who are "into art." He refuses to market his product. I kind of see a parallel here. Great code is great art. The next step is presenting it to people in a way which shows how it benefits them.

</comment><comment><USER7> An odd post from Jeff Atwood.

He (sort of) defines Marketing as:

       1. people understand what you're doing
       2. people become interested in what you're doing
       3. people get excited about what you're doing

I would say it was more about people understanding what your product can do for them, identifying it's value and thus parting with their money.

<comment><USER8> That's conflating marketing and advertising when they're actually two different things. Think of marketing as the social component of design.

You wouldn't start coding without at least a rudimentary spec to guide what it is you want to make, right? So why start designing your product without first identifying what and for whom it is you are designing it?

Marketing is the process of identifying the target market for your product. The "what it does" and "who it's for" part that a design needs if you're going to "build something people want".

<comment><USER7> I think you nicely describe the planning part of marketing - but you have to include the execution where you reach out to your target market. Advertising (in all it's forms) is a crucial tool of marketing.

<comment><USER8> Except that advertising isn't marketing: It's advertising. They're different things related to your business and should be handled differently.

I've run into a few companies who have painfully put an 'advertising guy' in charge of their marketing department and it's not worked well (in my limited sample). People are often great at advertising but couldn't put a decent product strategy together to save their life (or job!).

You wouldn't put your web developer or icon designer in charge of system administration or database scaling, right? Just like non-coders tend to lump everything technical together as 'computer stuff', technical folks can fall into the trap of lumping accounting, marketing, advertising, etc. into the same batch as 'business stuff'. That path leads to madness.

</comment></comment></comment></comment><comment><USER9> I like the fundamental premise of his post, but I am (metaphorically) downmodding it for presentation. His blog is beginning to look like it is hosted by INET-WEB: <http://www.inet-web.com/creativeGeniusWebDevelopers.asp>. Jokes aside, the danger I see here is that people might presume that when he says "marketing," he means bombarding people with gaudy images and superficial ornamentation.

That is __not __marketing. And furthermore, Jeff ought to know better. I suggest he read this:<http://www.codinghorror.com/blog/archives/000834.html>.

</comment><comment><USER10> Marketing vs. engineering is a common issue within a company and coming out of a failed startup - NOT marketing enough was part of the problem. The product did not sell itself, and many engineers mistakenly believe their product is simply that GREAT. It's often not (and I don't mean this negatively because engineering a GOOD product is very challenging to say the least), so be careful not to drink too much of your own kool-aid.

Historically, consumption has been driven by brand appeal which is defined by form (brand), function (product), and message (definition)... you'd be surprised how many great products have bad brands and lost in translation.

</comment><comment><USER11> I may be one of the few hackers that loves marketing as much as I do programming. I often split my reading time between both subjects. (And personal development.)

For me, marketing is exactly like hacking code. Except that it's hacking for humans! Even though humans tend to appear inconsistent, there are patterns (just like in code!) that you can leverage.

The bottom line is this: my marketing allows me to do more of the programming I love.

<comment><USER12> "We can debug relationships, but it's always good policy to consider the people themselves to be features. People get annoyed when you try to debug them." \--Larry Wall, second State of the Onion speech

"Identifying, anticipating and satisfying customer requirements profitably." Chartered Institute of Marketing's definition of Marketing

</comment></comment><comment><USER13> nice article, though i'm not sure that's the One Thing. my one thing would be 'know your audience'. that's part message and part usability. if you're designing an app for engineers you design the ui very different than if you're designing it to allow residents of the local retirement community to self- schedule dinner deliveries.

that said:

if you're a resident in a company with a separate marketing team, it's key to speak their language -- after all, the people you're going to be marketing -to- is the marketing team. it's their job to get the message out, it's your job to be sure they know what the message is, and what it isn't. make sure you don't oversell, and let them know what would be overselling, and promote key features internally; they'll get external through the firm's marketing wing.

if you're a startup, marketing is doubly important. if you can't sell a friend on the idea of a product, you won't be able to sell the public. if your startup idea is complex, you're going to have to find a way to make it intelligible in ten seconds by picking the key features you want understood. and everyone in a startup is on the marketing team, whether they like it or not.

it's really worth it to read a book or two on marketing, if for no other reason than to get the lingo down. i've found my suggestions much better received when i could speak market-speak to the marketing team and sales team, and promote effectively to civilians. i recommend 'the culting of brands' by doug atkin as a good start.

</comment><comment><USER14> My guess at the one thing:

Aim at the use, not the truth. Think about what it's supposed to _do_. This is helpful at all scales, from code snippet to a whole business. It's similar to finding the right question, before finding the right answer. Sometimes, it enables you to simplify dramatically.

</comment><comment><USER15> I don't think that lack of marketing skills is a real problem. You could have a friend that would do it for you. Think Steve Wozniak and Steve Jobs.

It's ok to be bad in marketing and good in hacking as long as you are not alone.

<comment><USER16> er, yeah, but look at where Jobs ended up versus Woz. Sure, Woz did well, but I can't help thinking he got taken advantage of along the way.

</comment></comment><comment><USER17> Part of the problem is that we look at marketing as being different than the hack. However, marketing is just social hacking. A true hacker isn't confined to one realm.

</comment><comment><USER18> If that were true then software teams would be make up of marketing gurus, who code on the side.

<comment><USER19> I've never seen a software team that didn't need to improve the way it communicated it's ideas to other areas of the business.

I've never seen another area of business that didn't need to improve the way it communicated it's ideas to the software team.

Marketing isn't a dirty word. It isn't advertising. It's the art of persuasion.

So, it is true, and in actual fact software teams would be made up of developers who are highly effective communicators.

<comment><USER20> You're absolutely right. In an ideal world software developers could do their art for the shear appreciation of it. But for practical reasons, we need money and other resources to do that. It only makes sense to convince others how valuable the craft is to them so that we are empowered to do it.

If smart engineers would just look at it as simply another problem to be solved -- people hacking -- we'd be set.</comment></comment></comment>


Microsoft Project Rome 1.0.0 - <AUTHOR> https://github.com/Microsoft/project-rome <comment><USER2> Yeah, that readme is atrocious. On the other hand, OP could have linked to something more informative, like this [1] or this [2] or this [3].

[1] [https://docs.microsoft.com/en-us/windows/project- rome/](https://docs.microsoft.com/en-us/windows/project-rome/) [2] [https://www.techgenyz.com/2019/01/30/microsoft-project- rome-...](https://www.techgenyz.com/2019/01/30/microsoft-project-rome-sdk/) [3] [https://developer.microsoft.com/en-us/windows/project- rome](https://developer.microsoft.com/en-us/windows/project-rome)

</comment><comment><USER3> I have looked at the repo and the website and I have no idea what this is or what it's targeted at.

It's a cross platform something?

<comment><USER4> The clue is in the name - Rome is a homophone of roam.

"Project Rome allows developers to write apps that can run on multiple devices and travel with the user as they switch between devices." [0]

So it's allowing a programmer to sync and script behaviours from Android/iOS phone to Windows desktop to xbox etc using a MS login.

I would assume it's the technology behind the _Your Phone Companion_ app that sends an SMS from a connected PC.

[0] [https://docs.microsoft.com/en-us/windows/project- rome/](https://docs.microsoft.com/en-us/windows/project-rome/)

</comment></comment><comment><USER5> A cross platform HandsOff[[https://developer.apple.com/handoff/](https://developer.apple.com/handoff/)]

<comment><USER6> Thank you!

</comment></comment><comment><USER7> > Build people centric experiences on all devices.

> A device-independent platform for building people-centric experiences that > span all devices.

I still don't get what it is.

</comment><comment><USER8> Nice,even their sample apps are only built in native instead of,you know,also adding their own crossplatform offering Xamarin?although i supposed their windows sample can be adapted. i wonder if Xamarin has been abandoned internally

<comment><USER9> The last commit in the Windows-specific code was in May 2017, only a year after Microsoft acquired Xamarin. Perhaps, there wasn't an internal push, by then, to go full-Xamarin for everything?

It looks like the Rome SDK, itself, (for Android and iOS) only went GA two days ago[0]; so the source code in the github repo was probably _way_ ahead of the curve, in terms of what would be supported at GA.

Maybe Xamarin, at the time, wasn't going to be supported but now is?

To allay your fears, here's the Xamarin sample[1] I found.

[0] - [https://blogs.windows.com/buildingapps/2019/01/29/announcing...](https://blogs.windows.com/buildingapps/2019/01/29/announcing- project-rome-sdk-for-android-and-ios-version-1-0/)

[1] - [https://github.com/Microsoft/project- rome/tree/0.8.1/Xamarin](https://github.com/Microsoft/project- rome/tree/0.8.1/Xamarin)</comment></comment>


Show HN: Yigler truly anonymous messaging - <AUTHOR> http://www.yigler.com

<comment><USER2> > Yigler let's you post anything you want anonymously, and see everything > people within 2 miles of you are posting.

In rural areas that makes you about as anonymous as if you signed your name to every posting.

<comment><AUTHOR> If there aren't a certain number of posts within the past few days then it expands the area you see until there are a good number of recent posts. But if you are in a busy area the minimum area is 2 miles.</comment></comment>


A deleted Wikipedia page speaks volumes about its biggest problem - <AUTHOR> https://www.fastcompany.com/90339700/a-deleted-wikipedia-page-speaks-volumes-about-its-biggest-problem <comment><USER2> That's a stupid article that's (a) only trying to create drama, and (b) by someone who doesn't understand Wikipedia and its rules and guidelines, and (c) doesn't even try to understand those before writing about it.

I mean I usually criticize Wikipedia heavily, as well, but this article is embarassing.

<comment><USER3> No its actually quite true there are a lot of self appointed "little hitlers".

I had to defend the second largest street festival in the UK from getting deleted.

I also had similar problems with a UK youth organisation similar to rotoract (youth arm of rotary) and the person doing that was some student from Germany

<comment><USER2> Nothing you wrote has anything to do with my comment. Please comment elsewhere. At the root, for example.

<comment><USER3> You said the article was stupid and implied it was incorrect I was providing some real world examples to back the articles thesis up.</comment></comment></comment></comment>


Vine passes Instagram in total Twitter shares - <AUTHOR> http://marketingland.com/vine-passes-instagram-total-twitter-shares-47579

<comment><USER2> I have a feeling the removal of the Instagram twitter card played no small role in this</comment>


Coming changes to Apple's App Store - <AUTHOR> http://www.theverge.com/2016/6/8/11880730/apple-app-store-subscription-update-phil-schiller-interview <comment><USER5> As someone who buys a lot of apps this is very disappointing. Things that would make me buy MORE apps (demos, upgrade pricing, better support) are still not in the app store, meanwhile the one pricing model I detest (subscriptions) is being added.

I suspect I'll be buying far fewer apps if there's a mass movement from a purchase model to a subscription model among app developers. I'm perfectly happy to pay $20-30 for an app (even a simple app) if it provides value and I'm happy to pay for major upgrades or additional content/features, but I won't pay $20-30 a year just to maintain the ability to launch an app on an ongoing basis.

In addition, after years of terrible search in the app store, coupling search improvements with search-based ads is just a kick in the shins.

<comment><USER6> I think the mindset change that needs to happen is this:

Apps are a service.

I would actually prefer to pay developers of apps that are truly useful to me a monthly amount so I know they can continue to update and improve the app. If an app saves me $1000/yr in headache, I'd prefer to spend $30/yr on a subscription rather than lose the app entirely because the developers can't keep the lights on.

<comment><USER7> There aren't many apps that can save you 1000/year. I keep hearing this, but that's nonsense. If a "service" is not producing money and isn't saving you time allowing you to produce money, then it's not worth paying for.

Yes, I have subscriptions for IntelliJ IDEA, for Dropbox, for FastMail and for a DigitalOcean VPS. All these are producing money for me. But the list ends here. Because here's the thing: $5/month here, $10/month there and pretty soon we're talking about serious money. Not only that, but as soon as you stop paying for whatever reason (eg temporary financial problems) you're out.

Of course, with our oversized salaries, we stop noticing that $5/month for a passwords app is actually expensive. And that's actually a good example because a passwords app at least has some utility.

More importantly, subscriptions are immoral because the end result is robbing users of any sense of ownership. And as a software developer, you no longer feel compelled to innovate, to improve, in order to convince users to upgrade. I for one hate renting things, I prefer ownership.

<comment><USER6> I want to address two things, here:

1) You're absolutely right: Pricing matters. If I charge you $10/mo for my app that sends you a text message every time there's a full moon, that would be way too expensive and you'd be well within your rights as a consumer to spend your money on something else. As far as I'm aware, Apple will not force you to subscribe to any apps.

2) "... subscriptions are immoral..." Bullshit. And you don't "own" software you buy and pay for once. Operating systems change. Companies and developers come and go. If you value a piece of software, then you value the developer and should desire that they maintain and improve the app.

What _is_ moral is creating a system by which software developers can support themselves by creating products that are useful to the community. I'd say the App Store is currently broken in that regard (with a few high-profile exceptions). If popularizing subscription-based pricing will help fix that, I'm all in favor.

<comment><USER8> Subscriptions _are_ immoral, but not for those reasons. It's an immoral business model because its success is based on bilking people -- cheating them into paying for 'service' when they don't want to.

The mechanism is simple: the slight inconvenience of cancellation prevents a huge number of users from cancelling as soon as they want to.

This is why getting your customers to set up _automated and recurring_ payments is the pot of gold everybody wants (not just in software).

You don't have to intend to bilk people if you do subscriptions; it's inherent in your business model.

Try putting a confirmation screen in your app that makes the user press "Renew" each month before the app charges them again. That would move you toward the moral end of the spectrum, but it would gut your sales.

A $2 per month subscription, even if totally unneeded, is not something most busy people can find the time to deal with cancelling. Pretty soon a year has gone by and your "service" has provided zero value to them but you've ripped them off for $24.

(For clarity: I don't mean _you_ personally, and also I do work in subscription-based software. I just don't have any illusions about it and it makes me feel icky.)

<comment><USER9> Quite obviously biased and overstated. Many subscription models have nothing to do with tricking people or making it hard to cancel and many customers of those continue to pay knowingly and willingly and appreciate the convenience of agreeing to this up-front instead of manually renewing multiple services each month. For example, my water provider. My Netflix subscription. You cannot just ignore this because it doesn't fit your model. The immorality is the trickery, not the subscription.

<comment><USER8> > _many customers of those continue to pay knowingly and willingly and > appreciate the convenience_

Yes, I fully agree.

> _Many subscription models have nothing to do with tricking people_

I don't agree with this, at least for auto-renewing subscriptions; that's my point. _Every_ piece of software sold on auto-renewing subscription has some significant number of subscribers (as a percentage of its total number of them) that don't actually want it.

That is true regardless of what the publisher intends or wants.

Obviously, the exact percentage will vary a great deal, depending on the product.

Water is an example of something where that percentage would be low — presumably, almost everybody wants their water to stay on.

Netflix, not so much; I myself once paid for Netflix for months, perhaps years, without using it once, and without wanting to keep it on "just in case". I was just too busy to cancel it the few times I thought of it (until I _finally_ did).

Netflix is not on the sleazier side of the spectrum, though; it's quite easy to cancel.

There are, however, a lot more disgusting sleazy fuckers out there like the Wall Street Journal, MyFico.com, and Comcast, than there are Netflixes.

P.S. As a bonus, here's my Second Law of Subscriptiodynamics:

 _The total difficulty in cancelling an isolated auto-renewing subscription always increases over time._

<comment><USER10> > I don't agree with this, at least for auto-renewing subscriptions; that's my > point. Every piece of software sold on auto-renewing subscription has some > significant number of subscribers (as a percentage of its total number of > them) that don't actually want it.

Some SaaS providers make unused subscriptions free of charge (Slack AFAIR), others auto-cancel them after a period of inactivity. This obviously only works if the provider has knowledge of whether a subscription is used, but it shows that the flaw is not inherent with subscriptions.

Other than that: I have quite a couple of pieces of software that I bought at pretty much full price and never really used. Is that immoral as well?

<comment><USER8> Detecting non-use and waiving all charges in that case? That not only nullifies all moral/ethical/assholiness problems with the subscription model, it is practically _heroic_.

But, I don't think that's very common.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> As an indie developer my single biggest gripe with the app store (after the obviously asinine review process) is the resetting of visible app reviews any time an app is updated. This is an incredibly expensive tax on shipping app updates which creates a strong disincentive to not incrementally improve your product and a strong incentive for sleazy developers to buy fake reviews when they do ship an update. I detest this part of the app store. DETEST.

<comment><USER12> The other option is for a single bug in a single release to stay in your app reviews in perpetuity. Why would you want that, rather than give prospective customers the option to look at current vs old reviews?

Also, I would quibble with your description of it as 'resetting of visible app reviews' as the old reviews are still visible, they're just one tap away...

<comment><USER13> In a high volume market like the iOS app store this behavior might be OK. It shouldn't take too long to get back a few reviews to display a N stars rating. (Just guessing, have no iOS apps in the store).

But in a low volume market like the Mac App Store it takes anywhere from a few weeks to months to get 5 reviews after an update. (Or even years in non US stores).

I made the experience that updating a well reviewed Mac app leads to a drop in sales until you get back to at least 5 ratings. (You need at least 5 ratings to display the average rating in search results and category lists in the Mac App Store).

This is a big incentive to keep updates back until it is really necessary to release them.

<comment><USER14> Yup. For that reason I've stopped releasing often and now have a beta program independent of the app store that people can opt into from the app itself.

</comment></comment></comment></comment><comment><USER15> Almost exactly one year ago, we switched Zombies, Run! - a fitness game - <USER2> being a paid app ($4-8) to a free-to-play app with subscriptions ($4/month, $20/year). Unsurprisingly, I'm delighted by this announcement, because it rewards apps like ours that provide long-term value and entertainment for our users.

Clearly a subscription model isn't for many apps - probably most apps. But it was right for us, as we've been maintaining and improving Zombies, Run! for over four years now, and every week we add new content. With a subscription model, we only get paid if people decide we're good enough to commit to over a long period of time. Since we're about helping people exercise, I think that's fair enough.

<comment><USER16> People fear that the subscription model is an easy grab for continued revenue.

I do think that Zombies, Run! is an example of an app that justifiably fits the subscription model. The continued added content makes that make sense. (I am a fan!)

I just hope subscription doesn't become the norm - I'd hate to see a calculator on a subscription model.

<comment><USER15> Yep, it works a lot better for some apps than others. To be fair, a calculator app doesn't need (as much) long term development or maintenance so I think a single payment is fine for both dev and customer there.

In light of this news, I wrote up a short post about how we made Zombies, Run! a subscriptions success:

[https://medium.com/@adrianhon/how-we-made-an-app-store- subsc...](https://medium.com/@adrianhon/how-we-made-an-app-store-subscription- success-25f4ea75500f#.mw4x9qghe)

</comment></comment></comment><comment><USER17> Subscription model for all apps...

I don't see a reason to subscribe for apps that are one-time pay and periodic long term use. There is a fine line here that developers will have to be cautious not to cross. A lot of apps have no reason to be subscription model, but the prospect of recurring revenue is too tempting.

Edit: On the other hand, this is totally awesome for services and products that already offer subscriptions on other platforms or on the web, like online streaming, education, and as someone mentioned here, tools like Sketch.

<comment><USER18> What do app developers do now when everyone has 1.0 and you want to release a 2.0 version with more features and not just bugfixes?

Do users still expect the upgrade for free?

<comment><USER19> That's a flaw in all app stores (perhaps by design to force everyone to a subscription model someday?). For example, ImageLine's FL Studio was warning everyone that their new app will be completely different than their old app, but they weren't able to change version for their customers by the store policies, so they were asking users to be careful about upgrade.

So currently your only option is to release app2, app3 etc. without the possibility to address your customer base (offering upgrades etc.)

Subscriptions are basically renting apps for regular time periods. If forced, this would kill all indies for sure as most people would spend budget to the few main apps they need. I can also barely envision how the platform would attract creative people as it would feel like oligopoly. Frankly, with computers we have a chance to break natural constraints on availability but companies seem to be hell bent on reintroducing the same stinky approaches from the past. Why?

<comment><USER20> "Frankly, with computers we have a chance to break natural constraints on availability but companies seem to be hell bent on reintroducing the same stinky approaches from the past. Why?"

Because I want to buy food and pay rent.

<comment><USER19> How does it help you if your potential customers avoid your software like a plague? Subscriptions border on restricting somebody's financial freedom. Imagine your plumber was forcing you to pay yearly for once/here and there using their services?

<comment><USER20> "How does it help you if your potential customers avoid your software like a plague?"

You're gonna have to show that would be the result. You'd also have to show that whatever your alternative idea is. You said you want to "break natural constraints on availability." How are you going to do that without charging per copy, or charing a subscription model? And how does your idea make more money that previous, or at least a similar amount?

"Subscriptions border on restricting somebody's financial freedom."

No, they don't.

<comment><USER19> I am fine buying software but only if I can keep ownership of whatever version I bought. I shelved money for complete CS6 but stay light years away from CC. I bought Ableton Live Suite, but stay away from ProTools. Imagine I had to pay Nikon or Access a yearly fee for camera/synth in my studio?

I have a plenty of money I want to spend on software but only if it empowers me and not if it treats me as an ATM. For example, the old JetBrains model of buying a new major release (and keeping it forever) and then getting free updates for a year was simply perfect, both for allowing developers to love the company that treats them properly and financing ongoing development; not sure why they regressed.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> One interesting side effect of this might be that reasonably priced single- payment apps might seem desirable again. If a lot of apps switch to a $0.99/month subscription, then even a $4.99 one time payment might seem ok, whereas right now it would considered expensive by most users.

<comment><USER22> One recent example on the Android side (don't use iOS very often) was an app that regularly publishes curated watch faces for Android Wear. There are literally thousands of free, user generated ones out there and I can make my own without too much trouble but I liked quite a few of the ones on this app.

Additionally, they allow designers to submit their own watch faces and share the revenue which I thought was cool. It helps combat the glut of "brand" knockoffs that fill many of the free/user-generated sites.

Originally, they offered a "pro" version that gave you access to all current and future watch faces for a subscription fee. I was not very keen on this because, like so many, I tend to forget to cancel these things when I stop using them. I mentioned this in an app review and so did many others. We requested a one-time IAP for the "Pro" version and soon after, the developer did just this.

So I paid $10 and every week or so I check out the new watch faces available for download. I like that some of the money goes to the platform and some to the designers. I like that the designs are high quality and don't include any knockoffs or blatant copyright infringement. And I like that I could just buy the full app after trying out the free options.

I've done the same with similar light-verion/paid-upgrade apps but this was the first one I'd run across that offered both a subscription or a one-time purchase.

</comment></comment><comment><USER23> "Part of that energy has been channeled into figuring out how to sell developers on subscription services, and not only that, but how to keep them keeping on with those subscriptions. Previously, only apps classified as news, cloud services, dating apps, or audio / video streaming apps could sell subscription content. Now it's open to all product categories.

For the first year of a subscription Apple will maintain its 70 / 30 revenue share; after one year, the new 85 percent / 15 percent revenue share will kick in (applied per subscriber). The new app subscription model will roll out to developers this fall, though if app makers have subscribers they've already retained for a year, the new revenue split starts June 13th."

That's a big change.

<comment><AUTHOR> Also: "Apple is also going to start showing search ads for apps in its iOS App Store search results for the first time, something the company had previously resisted."

<comment><USER24> I'm frankly shocked it took them this long. They have the #1 digital real estate for such advertising, and the amount of money being spent on advertising apps (particularly on FB) is staggering.

Unfortunately, from a user standpoint, this seems to be a disincentive to improve their horribly lacking search functionality.

</comment></comment></comment><comment><USER25> Apple has put up a "What's New in Subscriptions" site with a "Coming Soon" label: [https://developer.apple.com/app-store/subscriptions/whats- ne...](https://developer.apple.com/app-store/subscriptions/whats-new/)

Also for Search Ads (Coming this fall): [https://developer.apple.com/app- store/search-ads/](https://developer.apple.com/app-store/search-ads/)

</comment><comment><USER26> All I know is that their review process has gotten WAY faster and better over the last month, as in 24 hour review which has been awesome. Have other people noticed this?

I wonder if they added capacity or dropped review quality - so far we haven't seen a drop in quality and they are able to catch problems at about the same rate.

<comment><USER27> That change happened because App Store's management was transferred from Eddy Cue over to Phil Schiller. While Eddy Cue was completely deaf to developers' complaints and needs, Schiller seems to be giving a damn and he's trying to improve things. They now employ ML/algorithmic means to test submitted apps and catch simple rejection issues. I'm also pretty sure that if you have a pretty good record of submissions & approvals, they spend less time scrutinizing your app. And if you're just issuing fixes or simple changes, they don't spend any time "human testing" at all.

PS: I've come to a conclusion that whatever Cue runs, it is shit or turns to shit quickly. He's in charge of all the Apple services and they're a complete mess. I hope Cue retires or just transfers his responsibilities to someone who cares about them.

<comment><USER28> I don't think that everything he touches "is shit or turns to shit quickly". The Apple Online Store, iTunes Music Store, iCloud services, Apple Pay are all great products/servives. He took command over Maps when it was at a terrible stake, and it has improved a lot since.

However, I think iTunes, Apple Music and Siri all have weaknesses. But we can only guess who's fault that is - certainly not Cue's alone.

Also, he is employed by Apple since 1989. He must be doing something right.

<comment><USER27> Problem is that Apple's services are lagging behind their competition. Issue is that each team at Apple has their own stack. Imagine the amount of overlap that they have! They have hundreds of people who are doing the same work but for different teams. That also explains why Apple's so addicted to AWS/Azure/Google's cloud services.

And Siri's fallen further behind their competition. Don't forget, Siri was the first (major) assistant on the market and Apple had a year or two of head start on their competition. But that advantage quickly evaporated because of Apple's neglect. Siri's creators left and formed Viv because Apple lowered their ambitions and didn't give them the budget they wanted.

That's all Eddy Cue's fault since he's the one who's in charge of these teams. It's as simple as that. And just because he's been at Apple so long doesn't mean he's great at his job. It could as well mean that he's accumulated so much power that he's untouchable.

</comment></comment></comment></comment><comment><USER29> Bleh, subscriptions. I'm fine with them if your app is offering features that require use of your servers, but it seems many indie developers are interested instead in charging for the "privilege" of running local code on your device (as with Photoshop). I'll pass.

<comment><USER12> How about the 'privilege' of getting new features? Major app updates? Ongoing tech support and bug fixes?

One could argue that those should be included in the purchase price, but today's app store economy often doesn't allow that.

<comment><USER29> You're right — users shouldn't expect their apps to get major updates for free. But this is a PR problem, solvable by other means. As a user, I'm OK with it. I've been using Adobe CS 5 for the past 3 years and it's still working great. Were there an upgrade path where I could pay some cash and get the latest version, I would probably do so. Unfortunately, Adobe has decided that they're not the company for me, and so I've been happily moving on to alternatives like Pixelmator and Affinity Designer. From what I've seen in the response to Text Expander's subscription pricing and other similar business model changes, I think many others feel the same as I do: that above all else, the software running on their local machine must continue to work without having to pay a bloody tax.

A text expander is not a "service", nor is a password manager, nor is an audio looper or a to-do lister. To suggest otherwise would be disingenuous. Of course, we don't know what's going to happen in response to this change yet, but statements like Gruber's "win-win-win"[1] and Brent Simmons' request for clarification[2] indicate to me that indie developers will be more than happy to adopt this model with their decidedly non-service software.

[1]: [http://daringfireball.net/2016/06/the_new_app_store](http://daringfireball.net/2016/06/the_new_app_store)

[2]: [http://inessential.com/2016/06/08/seeking_clarification](http://inessential.com/2016/06/08/seeking_clarification)

</comment></comment></comment><comment><USER30> There are so many problems with the AppStore that need to be fixed and I hope atleast some are with these additions to the AppStore.

1\. Fix app discovery

2\. Fix app search before putting search ads. e.g. if your app name has a symbol in it searching by app name will NOT return your app in the search results.

3\. App review times can be further reduced by automating the review process

4\. Try it before you buy it option

5\. Better UX

<comment><USER31> Why would they fix product search when they can charge you to advertise your app in the search results instead?

<comment><USER30> same reason Google does it?

</comment></comment></comment><comment><USER32> Few customers realize that how much it costs to keep an app going: platform API and UI change will either break your app or uglify it. If the app is using external service, then the service API could change too and that causes a lot of work. New device models come, and you will need a lot of work in redesigning the user interface. Even if you are not adding new features, the cost is real to developers especially if the market for this app is small.

</comment><comment><USER33> I wonder if Apple is taking more than a 50% haircut on this post year one.

Credit card fees come out of their share and those could very well account for the bulk of the 15%. Even if Apple pays nothing in payment processor markup, there is a fixed minimum "interchange" cost that everyone has to pay (even Walmart). For "ecommerce" it's:[1]

Credit: $0.10 + 1.8-2.4%

Debit: $0.21 + 0.05%

Those 10-21 cent minimums make a big dent in smaller transactions. For a monthly recurring charge of $1.99, already 6% of that goes to credit card interchange. That leaves a 9% gross margin for Apple (4% if debit).

At $0.99, Apple's margin drops to 3% on credit, and they lose money on a debit card.

Now, there is a "small ticket" interchange category that one would hope these transactions would qualify for. That's just $0.04 + 1.65%. But it says it requires a swipe, so I'm not sure. From a fraud risk standpoint Apple Pay _should_ be treated _better_ than a swipe, but I'm not sure if the rules have caught up yet.

[1] [https://usa.visa.com/dam/VCOM/download/merchants/Visa-USA- In...](https://usa.visa.com/dam/VCOM/download/merchants/Visa-USA-Interchange- Reimbursement-Fees-2015-April-18.pdf)

<comment><USER34> Doesn't Apple bundle multiple purchases? Assuming someone has more than $0.99 in purchases via any of Apple's stores they can save on card fees.

<comment><USER33> For individual purchases it's only over a period of a couple days or so. Not sure about subscriptions.

</comment></comment></comment><comment><USER25> Interestingly Sketch app announced today they're changing to a subscription model soon. Sketch app abandoned Apple store last December. Looks like Sketch will be back to Mac App Store this fall.

It is sad that Apple only took action now, after years of requests and complains by indie developers. Now that app boom is over, I doubt this App Store changes will have any impact.

<comment><USER35> Oh damn it. Sketch 3 owner, this is news to me. As a hobbyist, their subscription price will almost certainly not be worth it.

The reason I quit Adobe and bought Sketch was to support software that I could actually buy. Not this "Good deal for professionals, even cheaper for students, fuck anybody who just wants to use a decent art program every couple of months" model.

I'll see what I can track down on details, but I'm preemptively very disappointed about this.

EDIT: Sketch is __NOT__ switching to a subscription model. Sketch is breaking from the "paid major, free minor" upgrade schedule, and going to "rolling releases, $99 buys the app and a year of upgrades."

Personally I think that's a fair system. It frees them from having to plan new features around the major/minor release schedule, but you can still buy the software and just keep using it.

My biggest concern is going to be OS compatibility. With OS X on a yearly upgrade treadmill, if there are any compatibility issues (and there almost always are), then the Sketch upgrade is effectively not optional. That's not so different from how it is now, except there have only been two major upgrades since the original release (September 2010), so you'll be buying OS compatibility fixes more than twice as often. So I still don't love it.

[https://blog.sketchapp.com/versioning-licensing-and- sketch-4...](https://blog.sketchapp.com/versioning-licensing-and- sketch-4-0-8ad98783e9ba)

<comment><USER36> > Sketch is _NOT_ switching to a subscription model.

It looks quite a bit like a subscription model to the average person. $99/year is a pretty big jump in price, but I guess they've gotten a chunk of pro market people. The whole bit about being unfair to late adopters is a bit of bunk.

<comment><USER35> > It looks quite a bit like a subscription model to the average person

Not really? My problem with subscription software is that you lose access to it if you stop paying. I used Photoshop 7 for a looooong time because we didn't need any of the new features. You can't do that with Photoshop CC. Because it's a subscription.

If anything, maybe you could call it an "update subscription," but if the software works without an active subscription, then it's not a subscription. That would be like Comcast saying "If you cancel your cable subscription, you can still turn on your TV and watch reruns of whatever aired when you were a customer."

> $99/year is a pretty big jump in price

For that much money, you could use Adobe Illustrator every January, May, and September!

<comment><USER36> Its still a subscription, it just allows an indefinite unpaid period until something breaks. There is no upgrade discount.

> For that much money, you could use Adobe Illustrator every January, May, and > September!

Illustrator is $19.99 per month paid monthly, so a little easier to handle but 2.4x more expensive. Illustrator has a lot more support but the difference in price just got reduced ($99 for about 2+ years versus per year).

Its about a 2x jump in price for Sketch.

I'm most saddened that neither company cares about customer loyalty in a money way.

</comment></comment></comment></comment></comment><comment><USER37> I detest subscriptions of all kinds. I don't want to manage them. I don't want to figure out how much I'm paying out per month across all types of subscriptions. I don't want a service to manage it for me, I just don't want the cognitive overhead. I don't want to remember the terms of each subscription, how long it takes to cancel (if and when I can get through to someone to cancel it). Or the fact that I lose access to something when I stop paying. I don't want to forget to cancel it only to find I'm bound to another 6 months. Etc, etc. I could go on.

I also strongly dislike that they know that x% of users after signing up will barely use the service and it's essentially free money. I know this is why they do it, and I won't support companies for trying to take advantage of users.

</comment><comment><USER38> the +15% more after a year is a joke. like this article mentioned - <USER3> majority of the apps are games, games after a year are usually forgotten and they make most of the revenue on their first year on the market.

about subscriptions - i don't see any reason a developer would share the subscriptions revenue with apple while they sale it for free and make in-app subscriptions.

</comment><comment><USER39> This won't substantially change anything, given the existing power-law type distribution of app-store earnings. When the ~app~ store debuted, I called it the K-Martization of software. This is just Apple expanding into Rent-A- Center.

</comment><comment><USER40> I wonder if this will further reinforce the notion of the "Dunbar's number of apps". In the sense that on a country-by-country basis, the disposable income of people could become the limiting factor affecting how many apps that users install.

If the supposed cognitive load of people for using apps is around 26-27, then is there an economic load that says that people will max at say--- $60/month--- in total app subscriptions in the US? And this number could change drastically for users in other countries based on fluctuating dollar values.

</comment><comment><USER41> Unless there's a legitimate reason for subscription (if it's cloud based and deals with private content) the law of supply and demand will kick in, which means it will work for these particular types of apps but won't work for others because there's always going to be a competitor who will provide the same service for free.

</comment><comment><USER42> In my opinion, the two most important features as a developer for the App Store:

1\. Rolling deploys - right now releasing on iOS is scary and big bang, combined with the review process it keeps devs up at night worrying. 2\. AB Testing on images and copy - you can only update this on each (scary) release, so you can't learn what works quickly.

</comment><comment><USER43> Am I the only one exhausted by "apps"? I've gone as far as to limit myself to only two pages worth on my phone, without folders. I feel like most apps could just be the mobile/responsive versions of the existing site. Maintaining separate interfaces always leads to inconsistencies.

<comment><USER44> If Apple supported the latest standards in mobile Safari, you could write web apps that work offline and have push notifications like on Android. That's not in Apple's interest though.

<comment><USER43> Serious question, why do we need apps that work offline? Finding it hard to imagine what you can do on a computer theses days without an internet connection, besides maybe an old single player game devoid of any patches.

<comment><USER44> It's not so much that you can _use_ it offline (though that's one benefit) but rather that it caches your assets so if there's very, very slow connection you can still use and read content. If it's something that requires the Internet to work, it can show a "no connection available" message but it still load, similar to a native app.

The goal is to avoid the "white screen of death" you get when a web app won't load.

Here's the canonical example: [http://www.pocketjavascript.com/blog/2015/11/23/introducing-...](http://www.pocketjavascript.com/blog/2015/11/23/introducing- pokedex-org)

</comment></comment></comment></comment><comment><USER45> Our business management app is free to use on iOS but we charge a monthly subscription to use the web client and that has been working pretty well. With these coming changes I wonder if it would make sense to start charging monthly subscription for Pro features on iOS and how users will react to that.

</comment><comment><USER46> Apple's revisions to the App Store reinforce that they consider it a rival to the World Wide Web.

Google cornered Web search. Reaction: As they own the walled garden, Apple completely control search within the App Store. Adwords owns Web Advertisitng. Reaction: Apple will launch paid search in the App Store. Companies like Netflix, Blizzard, and Salesforce have direct lines to their customer's wallets through subscriptions. Reaction: Apple will launch subscriptions in App Store and take a cut from their developers.

I don't see any of this as a surprise. In fact, I see it as Apple playing to their own strengths. The web is too open a platform for Apple, and history has shown they don't succeed when they don't have control.

<comment><USER47> Yes, the company that succeeds in the WWW is the company that has a monopoly in it.

</comment></comment><comment><USER48> I won't say that I really _like_ the idea of search ads, but I think it will be better than the current situation because it should at least reduce the amount of money that's currently spent on illegitimately gaming the search results.

</comment><comment><USER49> Wait until most apps have switched to subscription, sell yours for a one time price, profit from those users who hate subscriptions.

Maybe not sustainable, but hopefully keep you in the black until the next project.

</comment><comment><USER50> Reading this discussion, I've seen several comment on the "hassle of managing all those subscriptions". But wouldn't it be the case that the app store is going to do that for you, and give you both a single notification channel and a single point of management? Isn't that the whole purpose of managing the subscriptions through the app store instead of having customers visit your web site directly? Isn't that what Apple is getting %15 to perform?

</comment><comment><USER51> If a user doesn't renew their subscription in year 2, can they continue to use the "year 1 app" without receiving year 2 updates? Or does the year 1 app just go dark?

</comment><comment><USER13> > All he will say about free trials and paid updates is that Apple "looks at > everything. We evaluate what will be a better experience for the user, and > we make choices based on that."

How are free trials not a "better experience for the user"? I just don't understand Apple's paranoia when it comes to free trial versions.

</comment><comment><USER52> Death by a thousand cuts. All those apps that charge to turn off the ads? Suddenly you pay yearly for that. iAP to unlock those extra levels/features/etc, better pay the tax man because those will now be yearly. Apps will no longer be "upgraded" from 1.0 to 2.0 where you have to pay for the new version. No, you pay that yearly fee whether you like it or not. Sorry this isn't going to turn out well and I might just have to switch back to android where there are things like 2 hour to 48 hour return policies.

<comment><USER47> Ignorant comment, I bet you already use Android. Apple gives 14 DAYS of refund policy, and Google just copied Apple model.

Have fun with your LG.

<comment><USER52> I have an iPhone 6s. Can you show me where Apple says out right that they will refund an application before 14 days? I'm not being snarky, I just haven't seen that written before.

</comment></comment></comment><comment><USER53> Are these changes coming to the Mac App Store?

<comment><USER54> Yes. Gruber confirmed and there is a place on the site where OS X is mentioned.

</comment></comment><comment><USER19> How to kill your platform 101: Subscriptions

</comment><comment><USER55> I guess these are the kind of innovations we can look forward to while Cook is running Apple. :/

<comment><USER56> You can always switch to Android or Windows Phone if you like their innovations better.

</comment></comment><comment><USER57> This is a very un-apple way to announce major changes.

</comment><comment><USER58> I wonder if the ad-blocker works on those ads... :)

</comment><comment><USER59> Apple wants a subscription service because then they can hobble the developers AND the users to prevent them from ever leaving.

<comment><USER12> App subscriptions would likely lead to _more_ cross platform portability - <USER4> I'm paying $1/mo for your app, I won't care if it's on iOS this month and Windows Mobile next month, but if I paid $10 for your app, I don't want to repurchase it on a new platform.

</comment></comment><comment><USER60> They need to make cancelling subscriptions easier

<comment><USER12> it's like 3 clicks to find your entire list of subscriptions and once you're there it's 2 clicks to turn off automatic renewal. Plus TFA said they're making it even easier, so what exactly is your complaint?

<comment><USER60> on your phone? how? last I tried it involved going to iTunes on a desktop

<comment><USER12> In settings go to App Store, tap your account, then tap subscriptions.

</comment></comment></comment></comment><comment><USER61> Why not just A/B test trials & see how they do? Apple could be missing out on a sizable amount of revenue.

</comment><comment><USER62> What a terribly written article.

Just give me the TL;DR already please!

<comment><USER63> The giant graph showing the old revenue scheme vs. the new one was particularly unnecessary.

</comment></comment><comment><USER64> Apple is also going to start showing search ads for apps in its iOS App Store search results for the first time, something the company had previously resisted. "We've thought about how to carefully do it in a way that, first and foremost, customers will be happy with," Schiller says, adding that he believes the ad auction system in App Store search will be "fair to developers, and fair for indie developers, too."

Brace for the shitstorm

My comment on reddit:[https://www.reddit.com/r/apple/comments/4n62ny/app_store_20/](https://www.reddit.com/r/apple/comments/4n62ny/app_store_20/)

</comment><comment><USER65> > For the first year of a subscription Apple will maintain its 70 / 30 revenue > share; after one year, the new 85 percent / 15 percent revenue share will > kick in (applied per subscriber).

This is the exact opposite of what Apple should do. App startups in their first year need all the revenue they can get. After the first year, most of those companies have either reached profitability or gone out of business.

This policy is going to mean more revenue for the large, established app companies, like Instagram or Snapchat, and less revenue for any potential usurpers. They're effectively suppressing innovation and locking in any monopolies they've helped to build.

<comment><USER66> I think Apple is attempting to reward services and startups that are focused on long-term value for their users. If I create a subscription app, I want to get to that 85/15 split. So that means I need to build my business such that I'm around in a year to collect on that split and I'm providing a good enough service after a year that people stay subscribed.

In other words, I think Apple is intentionally discouraging companies that are so focused on the short game they may not be around in a year.</comment></comment>


Google's latest platform play is artificial intelligence,& it's already winning - <AUTHOR> https://www.theverge.com/2017/5/18/15657256/google-ai-machine-learning-tensorflow-io-2017-platform-play <comment><USER2> >For building AI tools, it's like the difference between a command line interface and a modern desktop OS.

What does that even mean?</comment>


A new model for microblogging - <AUTHOR> http://www.slideshare.net/duuble/presentation1-7803797

<comment><USER2> I visited the site and when I saw "Best viewed in Chrome, Safari and Opera." At the bottom of the page I left. But, I did read all of the elements all the way down to the bottom of the page. Well, not really, I was staring at that cool balloon.

You should have an "under construction" animated gif too. Since you are in beta an all.

Good luck!

<comment><AUTHOR> There were some problems when we tested it in IE and Firefox, so put that there. But we have changed it.</comment></comment>


Draft, Gitkube, Helm, Ksonnet, Metaparticle, Skaffold – Comparison of K8s Tools - <AUTHOR> https://blog.hasura.io/draft-vs-gitkube-vs-helm-vs-ksonnet-vs-metaparticle-vs-skaffold-f5aa9561f948 <comment><USER2> I'm going to use this opportunity to get up on my soap-box and talk about helm, the "recommended" way to install kubernetes packages.

Helm is not a useful abstraction, and needs to change in a BIG way before I consider using it over k8s_raw and ansible.

My main complaint with helm is that it doesn't allow one to develop decent abstractions over the core kubernetes resources. IMO it needs to move away from `gotpl` and implement the ability to use more sophisticated templating libraries.

I think this block of text elucidates my point:

```

metadata:

      name: {{ template "drupal.fullname" . }}

      labels:

        app: {{ template "drupal.fullname" . }}

        chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"

        release: "{{ .Release.Name }}"

        heritage: "{{ .Release.Service }}"

```

This block of code is in every single resource in every single helm chart. And it's one of MANY similar blocks of code that appear in basically every helm chart. I do not particularly enjoy writing the same massive YAML file over and over again.

Configuration management with helm is difficult. It would be nice to be able to declare "required" fields within an application, and enforce those fields with an error message if they are not provided. Currently, there is no way to do this other than having a "required" template that iterates through your "requiredFields" field and calls `{{ .Values.fieldName | required }}`

Interacting with the helm API server is difficult, which makes integrating helm with other configuration tools difficult. Specifically Ansible. This is also partly k8's fault ( And my fault, I suppose, because I could write it myself... ), because port-forwarding into the k8 server isn't implemented in any languages other than GoLang.

<comment><USER3> Agreed. Unstructured text templating to generate structures YAML is a terrible idea, which was previously shown with Ansible and Salt. (Salt provides a way to generate its YAML declaratively using Python, which seems to me a much better idea. Not sure about Ansible?)

I think Jsonnet is an intriguing idea here. Jsonnet is not well known, but apparently popular inside Google. It has variables and iteration, and allows you to cobble together structures by merging them, iterating over them, and so on, and the output is JSON, which happens to be what the Kubernetes API uses anyway. (There is a system that uses Jsonnet with Kubernetes, called Ksonnet, but that tool seems bafflingly overengineered to me.)

I've been dwelling on another idea: A system where you simply push all your templates -- what Helms calls a chart -- to Kubernetes as a single CRD (e.g. "kind: Template"). The templates reference variables, which you then push separately as another CRD ("kind: Vars"). Then the final component is a controller that listens to changes to templates and variables, and whenever one changes, expands the templates, compares them with the current manifests, and applies any differences.

To achieve controlled rollouts and rollbacks, you have a system on top that's similar to Helm, but it can be completely separate. You version the templates/vars as releases, not the underlying manifests generated by them.

<comment><USER4> Helm Version 3 will adopt CRDs for release and application state. There will no longer be a server side component (tiller).

It should be much easier to integrate other tools or templating systems with V3.

[https://github.com/kubernetes- helm/community/blob/master/hel...](https://github.com/kubernetes- helm/community/blob/master/helm-v3/000-helm-v3.md)

<comment><USER5> Interesting, but I never saw Tiller as an issue. Quite the opposite, I want less client and more server.

</comment></comment></comment></comment><comment><USER6> This article is pretty focused on the build type of k8s developer tools. There are other types as well that can fit into specific places in your workflow. Joe Beda does a fantastic high level overview of the different types in last week's #tgik8s: [https://www.youtube.com/watch?v=QW85Y0Ug3KY](https://www.youtube.com/watch?v=QW85Y0Ug3KY) .

Here's a couple tools that try to tackle this problem in different ways:

\- Ksync - `docker run -v local:remote` for your k8s cluster ([https://github.com/vapor-ware/ksync](https://github.com/vapor-ware/ksync))

\- Telepresence - extend the cluster network locally ([https://www.telepresence.io/](https://www.telepresence.io/))

\- Forge - end to end development through deployment ([https://forge.sh/](https://forge.sh/))

<comment><AUTHOR> Yes, ksync and telepresence lets you develop on k8s cluster as if you were doing on the local system. Haven't looked at forge yet.

These tools are really useful when you're writing code dependent on other components or features on the cluster (like DNS). They save you a lot of port forward, environment variable hassles. Gives high velocity development flows, which were quite long build-push-deploy workflows earlier.

</comment></comment><comment><USER7> The breadth of different tool styles for Kubernetes is really interesting.

At Airbnb we've built a tool that's most analogous to Ksonnet or Forge, but trades a lot of flexibility/extensibility for simplicity. We have this pre- baked model that your kube config has to fit into, and we don't allow much direct pass through from our config files to raw kubernetes manifest. The upside is that limits the divergence of configuration between any two services, which greatly reduces bus factor and improves maintain ability. I've seen many a nightmare in our chef monorepo – no need to go back to ultra- flexible (even Turing complete!) configuration.

Another key feature is that there's no special daemon or whatever required. Our build/deploy system runs the same commands you run on your laptop to build/deploy development versions to your dev kube. This increases anyone's ability to introspect and debug the system, versus a tool with a daemon that's doing who-knows-what, and you struggle to get debug access to the right parts.

I hope we can open source it one day, but right now it's under heavy development and has lots of Airbnb-specific magicks built-in.

</comment><comment><USER8> One tool not mentioned in the article is Jenkins X [0]. It leverages some of the technologies from draft to create a GitOps workflow for full build-push- deploy with CI and CD.

[0] [http://jenkins-x.io/](http://jenkins-x.io/)

<comment><USER9> One thing that differentiates these tools from Jenkins x is that they have synchronous flows rather than async webhooks model as in Jenkins x. The sync model is more apt for immediate feedback which you need in development phase.

</comment></comment><comment><USER10> [https://keel.sh/](https://keel.sh/) is also a great release manager / chatops framework.

edit: I had keel.io which is some random company. The site I wanted was keel.sh

<comment><USER11> spam? Link is about portfolio analysis.

<comment><USER2> I'm not spam! Also keel is completely free and open source!

Edit: I now see what happened, fixed.

<comment><USER11> Sorry, is the link wrong?

</comment></comment></comment></comment><comment><USER12> At GitLab we're building an automated workflow that takes you from zero to k8s called Auto DevOps.

Some of the interaction points between Auto DevOps and Kubernetes are:

\- deploying review apps

\- deploying production applications

\- supporting deployment of staging and canary environments

\- monitoring performance

You can also:

\- easily create a clusters on GKE through the GitLab UI

\- easily install "helper" applications to set up the cluster

\- easily install GitLab Runner to run Auto DevOps jobs on the cluster

You can read more about it here: [https://docs.gitlab.com/ee/topics/autodevops/](https://docs.gitlab.com/ee/topics/autodevops/)</comment>


Meet China's SexyCyborg, the goddess of geeks and hackers - <AUTHOR> http://www.atimes.com/article/meet-chinas-sexycyborg-goddess-geeks/ <comment><USER2> I know most Westerners are a bit taken aback at first but I'm an HN regular and around if anyone has any questions. FAQ is here: [http://pastebin.com/V3474kYs](http://pastebin.com/V3474kYs)

<comment><USER3> I've seen your stuff in r/DIY and it looks like your main interest (outside of your work as an RoR dev) is hardware. Do you code for fun or do anything on the software side as well?

<comment><USER2> >I've seen your stuff in r/DIY and it looks like your main interest (outside of your work as an RoR dev) is hardware. Do you code for fun or do anything on the software side as well?

No, software is just to mostly just to support myself. I know there's a push for being passionate, but sometimes the thing we love about our work is just that it lets us do the things we love. Also internet issues in China make coding even with a VPN not so fun. I'd like to be able to just do hardware projects if I could.

</comment></comment></comment><comment><USER4> i read the article but with a skeptical frame of mind (ie, "if she knows her stuff, why does she need to be so 'flashy'?") plus the title just made me cringe. A 180 change after reading it (plus a quick peek at a few of the S/C vids on youtube): the person behind 'SexyCyborg' seems to be bright, pragmatic, and honest (indeed, well beyond their years). As the the father of a six-year old girl, If this person has somehow become a role model "[t]o inspire young women to go into technology", seems to me they've earned it.

<comment><USER2> Thanks for giving me a chance before deciding, I really appreciate it. Some people are still not ok with it, and I totally understand, just so long as they get the whole picture first.</comment></comment>


Show HN: Me API – turn yourself into an open API - <AUTHOR> https://github.com/danfang/me-api <comment><USER3> Dan -- the themes and ideas behind this are rad and I'd love to chat with you to find out more about what you'd like to do with this.

I've been bootstrapping a concept that shares "the personal API" concept for 12 months now with a team of three and we're going to launch it in a couple of weeks.

Since other services' API rate limits and terms makes depending on them nearly impossible at scale, we decided to give everyone an API and a database.

The database stores data in community-driven schemas called the JSON Archetypes: [https://github.com/servant-app/json- archetypes](https://github.com/servant-app/json-archetypes).

The project is Servant -- The Amazing Personal Database ([https://www.servant.co](https://www.servant.co))

Anyway, I just starred the Me API. I'm in Oakland, if you're nearby, and you can contact me whenever you like: austen [at] servant.co I just like hanging with similar thinkers.

Cheers

<comment><USER4> I assume you are hosting these personal databases?

<comment><USER3> Yes

</comment></comment></comment><comment><AUTHOR> Hey guys! Thanks for checking out my little project.

Some background info: I was reflecting the other day on just how proprietary our online information seems. Maybe not proprietary, but definitely disjointed. We go to Twitter for social blurbs and trends, we go to Facebook to see our friends, Pinterest to see our interests, Github to see our code, etc etc.

I thought there was a big gap in getting access control to this information and that there are extremely powerful ways we can leverage all of this information. This essentially bootstraps the entire process of going through each social network's API and puts it in your hands. I think some interesting interfaces could come out of such an idea, although I'm not sure how well my implementation has allowed for that.

All in all, please give your feedback. I want to know areas where this is lacking, where you might see hidden opportunities - any reflection is appreciated!

<comment><USER5> Very cool space to play around in. You should check out Naveen's personal site (foursquare founder) as he was playing around with something similar for his own data a few years ago:

[http://api.naveen.com/](http://api.naveen.com/)

<comment><USER6> There was also the Locker Project ([http://lockerproject.org/](http://lockerproject.org/)), which I was keen to use and contribute to, but it stalled years ago.

</comment></comment></comment><comment><USER7> I had a similar idea -- however yours definitely is way more polished, especially during the setup phase. I definitely share your ideas of data liberation and open access. I've been meaning to add more endpoints to mine, but perhaps I'll move over to yours and just port the missing endpoints over.

Here's mine on github: [https://github.com/lukemiles/api.lukemil.es](https://github.com/lukemiles/api.lukemil.es)

Here's my website which is powered by it: [https://lukemil.es/is/](https://lukemil.es/is/) (sleep endpoint is currently disabled).

</comment><comment><USER8> Can we just call it finger2? Or json-finger? I mean, that's what it really is, just adjusted for today's reality.

I was surprised the readme in the project doesn't mention it.

<comment><AUTHOR> Hmmm, I never really thought of it like finger - that's a good analogy! I think there is potential for many other use cases rather than just for others viewing information about you though.

<comment><USER6> Related: WebFinger ([https://webfinger.net/](https://webfinger.net/))

</comment></comment></comment><comment><USER9> Very cool! Any thoughts about making it two-way at some point? For example, make sure that every network is updated if you change your name or email address.

</comment><comment><USER10> Or, if you already have a personal website, why not just use something like FOAF [1] via RDFa [2]? (granted, jCard is ugly)

[1] [http://xmlns.com/foaf/spec/](http://xmlns.com/foaf/spec/)

[2] [https://en.wikipedia.org/wiki/RDFa#Examples](https://en.wikipedia.org/wiki/RDFa#Examples)

</comment><comment><USER11> This is super cool. I never encountered something like this before, but seeing the comments, it seems there are a bunch of them out there. Will surely build mine.

</comment><comment><USER12> To make the schema a little bit more generic, have you considered changing the 'tech' node to 'skills'? Non-tech people could use it then.

<comment><AUTHOR> Hey Junto, it's a completely open schema as of right now. Feel free to add whatever fields you wish and render them as you will! What I have is just a template that works for me - think of me.json kind of like json-server, but all about you.

</comment></comment><comment><USER13> Anyone interested in this might look at [http://indiewebcamp.com/](http://indiewebcamp.com/)

</comment><comment><USER14> I think this is a fabulous idea. I will caveat that I don't code (yet) but can follow along several of the examples and I _think_ I "get it"...let me know if anything below is BS/way off.

I was thinking about the same problem a few weeks back when LinkedIn was s̶c̶r̶e̶w̶e̶i̶n̶g̶ ̶o̶v̶e̶r̶ ̶d̶e̶v̶e̶l̶o̶p̶e̶r̶s̶ improving their users experience. It's basically a fancy online resume with a graph that connects to so many people now that it's a crapshoot if people actually remember how they got connected in the first place. But I digress.

Thinking about how this sort of framework you've developed might be useful for an aggregated profile that can then be opened up as a proxy to various service/apps instead of actually giving direct access to your accounts (maybe have something like IFTTT to import your various social profile info into the Me API as it is updated):

\- Hate to allow apps to see all your github repos? Filter it via this service.

\- Dislike giving random apps access to your facebook likes, profile and other info? - use this service as a proxy to only present the info you feel comfortable with (maybe a maximum of 5 posts, or posts within a certain area/geofence, etc). Basically, you can create app permissions that are more granular than Facebook's out of the box preferences.

Of course - all this would need support from apps to tap into this data source (the Me API). It's an interesting idea.

Taking this a step further - I think it would be cool if it was somehow possible to obfuscate my identity - while sharing SOME of the "Me API" data with other services.

Some examples I'm thinking of (which may not be really possible - I realize the data provided could provide enough clues to be used to "uncover" my identity by piecing the datapoints together):

\- Allow a photo editing app to pull my SmugMug photos through the Me API endpoint, but keep my SmugMug account info obfuscated (ie: do not provide direct URL to my smugmug site's photos), but still pass over my actual photos.

\- Allow a mapping/analysis application to access my Yelp reviews by location, without knowing my actual yelp account info/nickname.

\- Pass over my LinkedIn graph (that I've manually downloaded as a CSV and ported into my Me API datastore) without providing access to my LinkedIn name or profile info. This could be used to help friends find jobs - <USER2> exposing my identity to a random webservice.

\- Pass over all my Google map searches/saved locations but don't provide any that are within 100 miles (+- 10 miles) of my home. Provide access to my phone number area code, but not my email address. etc.

The Larger Idea here: There are apps that can use your data to provide useful results/info/insights but ultimately the user (Me) should retain how much info is in fact exposed to the service. Maybe the service only gets a HashID or a Nickname - but can access a bunch of data that I give permission for it to access. Another application may get my whole profile, but not detailed transaction data. The webapps that leverage my profile info should "own" the graph of data they collect from Me and Others - but the user (Me) controls how identifying it is.

Sorry for the rambling, hopefully this isn't too crazy or off the wall. Either way - great idea and thanks for sharing!

<comment><USER15> I really like this idea FWIW. That said, there's some big barriers to making it a reality.

I think it'd be difficult to get enough external services to integrate into the personal service for grabbing Github/Yelp/etc. data. There'd have to be a standard of some sort that people were willing to build with. External services that want your data will ask you to oauth directly to Github et. all, or go around you to figure out who you are instead and then scraping pages.

You'd need enough people demanding to keep their data private to make it worth apps' time to do that.

</comment></comment><comment><USER16> Clearbit is another similar Service.

<comment><USER15> It is? Doesn't look like it. Looks like this is about turning your own data into an API, not another company selling data about you.</comment></comment>


Boiled Frogs and the Long Arc of History - <AUTHOR> http://squashed.tumblr.com/post/195883052/boiled-frogs-and-the-long-arc-of-history <comment><USER2> I'm going to completely ignore the political rhetoric that seems to be driving this, and wonder aloud myself - is there another analogy to replace the slanderous misrepresentation of a jacuzzi-bound frog?

Working on it right now ... watch for updates!

Edit: There's a reasonably well-known poem by Martin Niemöller - "First they came for the Communists, and I did not speak out for I was not a communist etc". Seems to convey the same concern regarding a creeping threat, though without the solid visual of a frog. <http://en.wikipedia.org/wiki/First_they_came..>.

Edit 2: Spent some time rolling through options - a car that needs regular servicing, because incremental wear and tear will stop it; a fish in a pond that begins drying up, not leaving until it's too late to escape; even comparisons to compound interest or the 'one cigarette won't kill me' school of thought.

Then I realised I'd been sucked in by the assertion that a comparison didn't exist - when one does.

It's the Turkey that doesn't have an appetite off switch - if you keep putting food in front of it, it will keep eating until it dies.

Seems a relevant analogy. Now whether _its_ true is a subject to research.

<comment><USER3> See James Fallows's post _Once and for all with the frogs_

[http://jamesfallows.theatlantic.com/archives/2009/09/once_an...](http://jamesfallows.theatlantic.com/archives/2009/09/once_and_for_all_with_the_frog.php)

for a great kitty litter box analogy...

</comment></comment><comment><USER4> The boiling frog story is true. [http://books.google.com/books?id=Hr0aAAAAMAAJ&pg=PA299&#...
The modern researchers who "debunked" it simply heated up the water too quickly.</comment>


Another toll of the drought: Land is sinking in San Joaquin Valley - <AUTHOR> http://www.latimes.com/local/lanow/la-me-ln-groundwater-20150819-story.html <comment><USER2> Almonds, what about rice?

<comment><USER3> Rice and almonds appear wasteful when measured by mass produced per unit of water used, but that's not a particularly useful measure for food. More useful is calories per unit of water and protein per unit of water.

Rice measured by calories per unit of water is more efficient than lettuce, celery, tomatoes, spinach, cauliflower, lemons, raspberries, peaches, and broccoli. It's less efficient than carrots and strawberries.

National Geographic has a nice interactive display of the efficiency of various crops as measured by three factors (water/weight, water/calories, and water/protein) here: [http://news.nationalgeographic.com/2015/05/150508-which- cali...](http://news.nationalgeographic.com/2015/05/150508-which-california- exports-crops-are-worth-the-water/)

</comment></comment><comment><USER4> Demonizing farmers for the water crisis is _completely missing the issue_. The fault lies at the feet of environmentalists and politicians who stopped building water infrastructure in proportion to the growing state population. LA is naturally a desert. SF cannot supply all of its water locally. Water infrastructure is _necessary_ for humans to live in most regions of California and we have been living off infrastructure investments made 50+ years ago.

This is a must-read to understand what's been going on: [http://www.hoover.org/research/dry-winters- tale](http://www.hoover.org/research/dry-winters-tale)

 _" Just as California's freeways were designed to grow to meet increased traffic, the state's vast water projects were engineered to expand with the population. Many assumed that the state would finish planned additions to the California State Water Project and its ancillaries. But in the 1960s and early 1970s, no one anticipated that the then-nascent environmental move-ment would one day go to court to stop most new dam construction, including the 14,000-acre Sites Reser- voir on the Sacramento River near Maxwell; the Los Banos Grandes facility, along a section of the California Aqueduct in Merced County; and the Temper-ance Flat Reservoir, above Millerton Lake north of Fresno. Had the gigantic Klamath River diversion project not likewise been canceled in the 1970s, the resulting Ah Pah reservoir would have been the state's largest man-made reservoir. At two-thirds the size of Lake Mead, it might have stored fifteen million acre-feet of water, enough to supply San Francisco for thirty years. California's water-storage capacity would be nearly double what it is today had these plans come to fruition. It was just as difficult to imagine that envi-ronmentalists would try to divert contracted irrigation and municipal water from already-established reservoirs. Yet they did just that, and subsequently moved to freeze California's water-storage resources at 1970s capacities...

In reaction to these ongoing disasters and fearing a fourth year of drought, the legislature and Governor Jerry Brown placed a $7.5 billion water bond on the November 2014 ballot. It passed, but only a third of the money will go to construction of reservoirs canceled in the 1970s and 1980s. Most of the bond's provisions will fund huge new state bureaucracies to regulate access to groundwater and mandate recycling. The bond will essentially void more than a century of complex water law as the state moves to curb farmers' ability to pump water from beneath their own lands. Bay Area legislators who helped draft the bill failed to grasp that farmers' drilling and pumping is driven not by greed or insensitivity to the environment but by a doubling in the state's population and a water infrastructure that has not kept pace. A better way to regulate overdrafts of the water table would have been to increase vastly the reservoir surface water for agriculture so farmers would have no need to turn on their pumps...

Continuing drought means vast tracts of westside farmlands will turn to dust. California's nearly $30 billion agricultural export industry—led by dairy, almond, and grape production—is in grave peril. Its collapse would crush the economic livelihood of the Central Valley, especially its Hispanic com-munity. When the five-million-acre west side goes dry, hundreds of thousands of people will lose their jobs in a part of the state where the average unem-ployment rate still hovers above 10 percent. Farmers will spend hundreds of millions of dollars to further deepen their wells and save what water they can. Everything they and their predecessors have known for a century will be threatened with extinction.

Water use in California is being curtailed by those least affected, if affected at all, by the consequences of their advocacy. But environmental- ists, who for forty years worked to undermine the prudent expansion of the state's water infrastructure, have a rendezvous with those consequences soon. No reservoir water is left for them to divert—none for the reintroduc-tion of their salmon, none for the Delta smelt. Their one hope is to claim possession of the water in the ground once they've exhausted what was above it...

Now that no more reservoir water remains to divert, the exasperated left is damning "corporate" agriculture ("Big Ag") for "wasting" water on things like hundreds of thousands of acres of almonds and non-wine grapes. But corporate giants like "Big Apple," "Big Google," and "Big Facebook" assume that their multimillion-person landscapes sit atop an aquifer. They don't—at least, not one large enough to service their growing populations. I have never met a Bay Area environmentalist or Silicon Valley grandee who didn't drink or shower with water imported from a far distant water project. And as the Hetch Hetchy Reservoir drains, Bay Area man-made stor-age lakes will necessarily follow. Another year of drought will deplete even Southern California's municipal reserves sooner rather than later. When Silicon Valley tech lords and academics can't take a shower and find them-selves paving over their lawns and gardens or letting their pools stand empty, perhaps they, too, will see the value of reservoir water for people rather than for fish. The new dust bowl may see a different generation of Joads abandon-ing California for a wetter—and more prosperous—Midwest."_

<comment><USER5> > Demonizing farmers for the water crisis is completely missing the issue. The > fault lies at the feet of environmentalists and politicians who stopped > building water infrastructure in proportion to the growing state population. > LA is naturally a desert. SF cannot supply all of its water locally. Water > infrastructure is necessary for humans to live in most regions of California > and we have been living off infrastructure investments made 50+ years ago.

If you reduced direct human usage of water to _ZERO_ in California, you still wouldn't have enough water for agribusinesses.

This is playing out. As water prices rise, the coastal cities will turn to desalinization, and the agribusinesses will be left to knife each other.

</comment></comment><comment><USER6> I am in the UK and I brought almond hair oil - at the back it said "almonds grown in California".

How does this make any sense ?

Its not even almond but almond OIL. Knowing what I know now I look at the bottle and wonder how many thirsty Californian babies did I just kill buying this.

Its the same feeling you get when wearing Nike shoes that you know were made in some sweatshop.

<comment><USER7> Just for perspective:

There isn't any kind of issue where people aren't getting water to drink, but yes, growing almonds is fucking stupid in a drought ridden state.

<comment><USER8> > growing almonds is fucking stupid in a drought ridden state.

I've seen this sentiment a few times, and it's never made sense. Crop growth isn't determined solely by water availability. There's plenty of water in Florida, but the climate there is likely less almond-friendly than the California climate. In a toy world with just those two states, you'd have to pick your preference: climate control in Florida, or water importing in California. Saying they're both just something an idiot would try to do is giving up on the whole idea of growing almonds in particular and of comparative advantage generally. Maybe California's exceptional climate justifies doing a certain amount of work you wouldn't have to do to grow crops somewhere else.

I've also seen two more sensible points about almonds and California water:

\- It's difficult to make property rights in water work, because two people drawing from two wells into the same aquifer both just lower the level of the aquifer everywhere. Off the top of my head, you'd need tradable allotments, like ocean fisheries, rather than property lines which I believe are what we currently use.

\- If you own a field and want to grow alfalfa (hugely water intensive), you can just let the field lie fallow if the price of water goes too high. You'll lose that year's alfalfa crop. But, if you own an almond orchard, you can't abandon it just because it'll cost more money to water it than you can make back selling the almonds -- if you don't water your orchard, all of the trees will die, and you won't own an almond orchard anymore. Since the California precipitation cycle is much longer than one year, it might be good policy to discourage crops that require maintenance on a yearly basis.

<comment><USER9> Seems like a false dichotomy, you could also just have zero almonds and grow something else.

<comment><USER8> >> Saying they're both just something an idiot would try to do is giving up on the whole idea of growing almonds in particular</comment></comment></comment></comment></comment>