Dear Client: Stop Asking for a Ballpark Estimate - <AUTHOR> http://www.christopherhawkins.com/2016/05/ballpark-estimate/ <comment><USER2> Here's a secret for consultants: the attitude espoused in this blog post is losing you sales.

Any decent client understands that you can't give them a fully spec'd estimate before you've even begun the engagement. But they want to understand what the process will be, and yes--that includes what the ticket price might look like.

Having been on both sides of this exchange, I _really, truly_ understand why ballpark estimates are hard. But I also understand that approximately nobody is going to approve an expense without having any idea of how large or small it might be.

<comment><USER3> This.

The point of a ballpark estimate is to answer the question, "Is this in the ballpark?" Namely, can I afford it? Is it _even worth_ paying you $1,000 for a discovery session if the implementation is going to cost me 10x my budget in any case? _Is it worth taking the next meeting with you?_

The author is right about anchoring to value, and the author is right that it's impossible to fully-scope a project in a minimal amount of time.

But you're the expert! So the right answer is: "We'd look to get a lot more accurate on cost, and a Discovery Session might be a good way to get you an accurate estimate on the cheap. But to get you a sense of magnitude, similar clients have paid $x-(x+20%) and have seen 10x returns. How does that fit into both your budget and the business case you had in mind?"

<comment><USER4> >> Here's a secret for consultants: the attitude espoused in this blog post is losing you sales. <<

That's correct. This makes me sound bitter, but here's how it really works:

They ask for a ballpark estimate, and you quickly throw out a number that's believable but not too high so as to scare them off. This is usually done by a sales person who IM'd a free developer and gave a two or three line summary of what the client is suggesting.

Then there is some back and forth, where they customer adds or removes requirements, and the number changes somewhat accordingly, but really, in the context of sales, not technical challenge. "Oh we wrote X for some other client a while back, we'll throw that in for free."

Then it might get complicated, and you get nervous, and you suggest having the client pay to do a detailed analysis. The customer says no, cause, you know, those ballparks are awesome and free.

You agree on an approximate number and contracts are written up. Because really, the ballpark is the actual estimate. We were fools to think otherwise. But of course there is lots of wiggle room and vagueness written into the contract because you nor the client didn't really want to spend much time fleshing it out.

Customer signs. Contrary to what you might think, you just won! You hooked 'em!

Now, you work on the project, and maybe you hit the ballpark, and maybe you don't. If you don't you go back to the client and say, "Well, you know it was just a ballpark estimate, we had lots of new things come up, and you added this and that, and now it's going to cost more money."

Customer can't argue too much, because they didn't want to pay for a detailed analysis, and they did ask for a ballpark. And now they're already in it for some money, and to bail now would mean losing that investment. So they spend more.

Lather, rinse, repeat until the project is done or the customer is out of money.

Now don't think I don't find this system awful - I do. But that's how it works. You'll never get it to change because it will always involve ignorant sales people and ignorant business owners, and they are playing a social game, not detailing a technical endeavor.

<comment><USER5> Correct. And charging a "small" amount to gather requirements is a quick and easy way for the consultant to determine if the potential customer is a good fit. A customer that understand that spec work takes time and resources and is willing to pay for the work is also a potential client that will, when they make change requests or feature/scope creep, understand that they should/will be paying for those on top of what the spec says. Everyone is correct that the author is losing business by working the way he does... but he's okay with that because he's cares more about client/customer fit (and quality) than work volume.

</comment></comment></comment></comment><comment><USER6> Stop complaining.

Figuring out how to artfully discuss price is _why you 're qualified to run an agency_ (including the world's smallest agency) in the first place. If you can't do it without getting annoyed at the client go work hourly or for a salary. That's an option too.

I'm always amused by people who think running a service based business would be easy, if it wasn't for all the damm paperwork, dealing with taxes, employees/partners who flake out or need babysitting, clients who are hard to please, and collections issues.

It's not that I don't feel their pain. But that's what running a business means.

His main insight here is insisting on a paid estimate. Sure, that's an option if your reputation is strong enough to be able to stay busy in spite of it, but it's hardly a novel idea.

Ask any auto diagnostics mechanic. Who, by the way, will still be able to give you some kind of best/worst case scenario and ballpark range verbally. It's not actually that hard.

<comment><USER7> > Ask any auto diagnostics mechanic. Who, by the way, will still be able to > give you some kind of best/worst case scenario and ballpark range verbally. > It's not actually that hard.

One of the author's points, and one with which I agree, is that it's _significantly harder_ to estimate software projects than, e.g. repairing an automobile.

</comment></comment><comment><AUTHOR> I love you guys so hard right now. Great comments, lots of good points that are clearly informed by plenty of client-project experience, and even a couple of things I didn't think to consider.

Real quick:

1) Bear in mind that nowhere in the article do I _refuse_ to give ballpark estimates; I'm simply pointing out the downsides and offering a potential solution.

2) I know my site is horrible, and I knew that YOU would know my site is horrible! The new one is under development and should ship in another week or two, but _shrug_. The cobbler's children have no shoes sometimes. ;)

3) You folks who are suggesting order-of-magnitude estimates are _spot-on_, and this is more-or-less what I've learned to do over the years when giving _some_ kind of an answer is critical to maintaining the life of a potential deal. _Sometimes_ the order-of-magnitude thing can backfire, though, particularly when the client is thinking in "cost" mode rather than "return on investment" mode.

4) Pointing out the downside of a thing and offering a better alternative does not constitute "complaining" insofar as I understand the term; rather, I think of it as problem-solving.

5) "Dear Programmers: Stop Giving Me a Ballpark Lines of Code Estimate" is fucking hilarious and I love you for thinking of it. :)

OK, that's all I have time for, gotta run!

</comment><comment><USER8> Dear IT Consultancy Principle, you just do not get it. I am a business person, and yes, I do need a ballpark estimate. I do not know what I am asking for is 10 minutes of work or 10 years. Please help me narrow down my expectations. Is it 10 days, or 10 weeks, or 10 months? I really do not know. Your company has done some good work for me and I trust your judgement. Please give me a very estimate of what I am asking for is reasonably achievable. If yes, then awesome, let us proceed to the next stage. If no, then please help whittle down my request into something more simple, and easily achievable.

\--I am an internal IT and Development Manager. I work with internal clients everyday who do not know what they are asking for is a simple content change, or a major architectural rethink. My internal clients need some help with the /business analysis/ of what they are asking for is a sensible thing. They do not know if a series of pages only accessible to their external client is something simple for us to achieve, or something that will take a decade. They really don't. Their job is to drive things forward for their clients, and my job is to look at what all their requests look like across our company and push forward the things that will help everyone.

Your job as a consultancy is to help us clients determine what is low hanging fruit and what is not. You might have something easy to ship as a client data access system, and it would take you 10 days or 10 weeks. Or it might take you 10 months. Or it might take you 10 years. The company I work for for could probably do A, B, or C, but definitely not D. If it is D, then how can we simplify the requirement? That is _your_ job as a consultant.

<comment><USER9> I think this post has some very good concepts and points that were not touched on much. I feel like I could do business with you lol

</comment></comment><comment><USER10> I'll have to (mostly) disagree on this one (although I do think he raises a VERY valid point at the end).

The author is very vague on how the conversation with the "business owner" goes, and I agree that giving an anchor point is very, very dangerous, but as someone who has been on both sides of the table, you CAN and SHOULD give an order-of-magnitude estimate with several very clear caveats.

And I disagree that asking for a ballpark estimate translates to "So, can you guess exactly what's required... (etc.)". It's the opposite of that, it's can you ROUGHLY (not "exactly") guess (yes, you do have to guess, that's what estimates are, guesses).

I agree that only the people actually building can give a "real estimate".. but you can give a "ballpark estimate" (which I translate to order-of- magnitude estimate).

The one valuable point from the article is "You're focused on the wrong thing.". Yes, you should help the business owner focus on the ROI. But you can tell him whether it's a job for a $ 1.000 static website, a $ 10.000 web app, a $ 100.000 system with web, mobile and whatever, or a $1.000.000 ERP or whatever. (or outline to him the options)

Edit: I agree with yardie ( [https://news.ycombinator.com/item?id=11741006](https://news.ycombinator.com/item?id=11741006) ) and napoleond ( [https://news.ycombinator.com/item?id=11740951](https://news.ycombinator.com/item?id=11740951) )

<comment><USER11> I wonder if there's value in simply answering with an order of magnitude...

"Based on our discussions so far, a basic web application would fit your requirements. We typically build those with a budget of tens-of-thousands."

(OK, maybe with less awkward delivery, but you get the point.)

<comment><USER12> I think it's pretty valuable. After hearing such an estimate, the client may think "oh, it might stress the budget a bit; I'll need to double-check with my boss". Or, "what? I thought it will cost like $100!". Both are valuable conclusions.

</comment></comment></comment><comment><USER13> The problem with this article is not any of the facts or reasoning which is all very spot on. The problem is the tone. From the very opening of the title "Dear Client" it's hard not to read this in a sneering, condescending tone. At best, it preaches to the choir, and will never be discovered by the people who need it most.

A necessary component of a good client-consultant relationship is mutual trust and respect. If the client is well-intentioned but ignorant, then there is a much nicer way of educating them, on the other hand if the client is stubborn and arrogant then you don't want to work with them anyway. On the flip side, you should respect your client's expertise, not pretend like running a consultancy is the same as running other types of business.

I understand the emotional appeal of writing a screed like this, I've worked with my fair sure of clueless and bull-headed clients (eg. many realtors during 2006-2007 bubble), but if you are as good as you think you are you can't let yourself get dragged into this embittered attitude as it will turn off potentially good clients as well.

<comment><USER8> Yes, this. As a "good" client, please help me get a sense of the spend that I will need to budget for, and the time it will take. That is what I am asking for by a "ballpark". This idea maybe totally simple, or able to do with some effort, or very difficult with concerted effort. Please give me a 'rough' estimate. From there we can formulate a more concrete action plan. Maybe that is some consultancy time, or maybe I have to drop this idea. I get that a $1000 or £1000 will help focus the clients mind on whether this is a worth while venture, but please just keep it simple.

</comment></comment><comment><USER14> Thats not a ballpark figure thats an estimate. A ballpark figure should be within magnitude. That way the client can decide if they want to pursue the project at all. It's just a spread so someone that doesn't have any knowledge has realistic figures to work with.

If someone asks for a basic 3-page site I can ballpark it to $500. Most likely it will be less, sometimes it will be higher. If they ask for an iOS app I can ballpark and say $5000. If it's $1000 we're in the ballpark. $10000 and we're still in the park.

<comment><USER15> The problem is, frequently even an order of magnitude isn't even enough. For instance, a high profile 3 page site that has a large number of daily visitors (or a product launch). Since the cost of getting something wrong on this may be so high, you need to get things right. This involves numerous rounds of usability testing, often multiple different comps, load testing, etc. It's totally reasonable for the budget of a 3 page site to cost upwards of $50k.

On the flip side, an order of magnitude may be too much. Your example ballpark for an iOS app, to me at least is easily already off by an order of magnitude. The _minimum_ I could reasonable expect an iOS app to cost would be $50k, and if we're shooting for an order of magnitude, I'd have to say $500k, which could be $50k on the low end or $5m on the high end. That's a pretty huge range of prices. Almost not even worth giving a ballpark at that point.

<comment><USER16> > The problem is, frequently even an order of magnitude isn't even enough.

"$500 if it's just a 3-page site, but if you expect a large number of visitors, it can easily jump to $10,000 to $50,000 when all is said and done. Sounds like you have an interesting project with lots of variables. Let's talk more."

</comment></comment></comment><comment><USER17> Companies that refuse to publish or even respond to quick, direct questions about pricing fail to understand something very important: whatever they are selling is only a part of whatever I'm working on, and is almost certainly not the linchpin of the project. I may have a dozen more vendors to talk to that week, and I literally cannot afford to waste time schmoozing with sales droids, waiting for calls or emails to be returned, or establishing a "relationship." Making me jump through hoops just to understand the pricing model is basically their way of telling me I'm not worth their time.

Which, of course, may be true.

For now.

<comment><USER7> I think you're referring to very different products or services than custom software development. Or would you be satisfied with "$200 per hour billed"?

For fixed, static products or existing and relatively simple services? I absolutely agree that a clear pricing model is a reasonable expectation.

</comment></comment><comment><USER9> It appears to me much of the problem written about in this article is the client not knowing what they wanted from the start and explaining it.

If a client simply says, "how much to build cool stuff?" I cant answer because I have no idea what they mean by "cool stuff". In order to help them they have to give me more details of what they want. Which in some ways is a warning sign to me about the client, if they don't really know what they want it already makes me question if I even want them as a client. Them knowing what they want directly relates to my ability to tell if I can make them happy.

My approach is "well before we get to ballpark let me know some more information about what you are looking for so I can make sure I get this as close as possible."

I call this hand holding, you hold their hand and you walk em through it if you think they are worth it, or you cut em off early and don't waste your time. I learned a long time ago some clients are not worth it.

Also I wouldn't make a post with this sort of tone and tie it directly to yourself, I know exactly what you mean but to others it may come off in a "negative" light. A potential customer can read this and think well I like ballparks and don't want to get lectured about it so forget this guy. I would take more of the positive approach and frame it as "Dear client let me help you get a better ballpark figure".

</comment><comment><USER18> Completely disagree. Can't put it more plainly than as satire:

"Dear Programmers: Stop Giving Me a Ballpark Lines of Code Estimate

Once a programmer and I are past finalizing requirements and have selected a stack (or they are contributing to an existing project) I need to know exactly how many lines of code they will be writing for the functionality. I need this for my accounting requirements.

Stop giving me ballpark estimates like "a few hundred" or "thousands" or "well, it depends on whether I can use an external module, can I get back to you?"

That is unacceptable. Once we have agreed on requirements, I will be paying for your "discovery session" where you must sit down and discover exactly how many lines of code you will be writing.

At the end of the day, you're the one writing it. Only you know what that number will be.

I require an exact number of lines of code that I will be paying for. 7,428 lines of code is not the same as 9,416 lines of code. The difference between 7,428 and 9,416 is the same as the difference 3 and 1988. Likewise, the difference between 76 and 7,428 or between 7,428 and 14780, or between 458,583 and 465,935 LOC are exactly the same. (in each case it's a difference of 7352.)

If you expect me to pay you to discover my requirements, do you expect me to be able to pay you to discover your requirements?

Or is there some sense of scale that you can have some kind of understanding of?"

According to the author, there is not.

<comment><USER7> I don't get your point. You're satirizing someone caring about the cost of a project by comparing it to someone caring about the number of lines of code written?

<comment><USER18> Yes. I disagree with paying to find out the ballpark, and compare it to paying to figure out the number of lines of code without writing them. It's not a good way to do business. I don't think the author's idea is viable and I agree with the other poster who said that the author was probably losing business as a result.

</comment></comment></comment><comment><USER19> I enjoyed the article, and checked out your site: [http://www.cogeian.com/](http://www.cogeian.com/)

Here's some free, hopefully constructive advice. Your site does not look professional. It looks like something I'd expect a welding company to have in the early 2000's. I'd highly recommend redoing it with a more modern design, especially if you're trying to get potential clients through it.

<comment><USER20> So here's some constructive criticism for your constructive criticism. Your heart is in the right place but unfortunately your criticism isn't that constructive. Just saying "Your thing you think looks good actually looks bad. Fix it." is really more of a soft-pitch put-down.

Constructive criticism points out what's good about something and how it can be improved. It's specific and provides actionable guidance.

1) The site would benefit by leading the eye in a more controlled manner. Right now there are at least two groups of three or more columns so it's hard to know where to look. Take a look at brick wall designs such as Twitter Bootstrap. Lead from general at the top to more specific, detailed information as you go down the page. Imaging the page as a tree diagram.

2) Make the site "say more" by reducing content. Right now there are at least two places on the page that talk about what you do, who you are, and what you're about. Combine those to be more succinct.

3) The color scheme is changing to match the client you're highlighting and that's kind of cool. It's also kind of cool how you show a different client each page visit. But I think a slider would do a better job there. Do you expect more than one visit to evaluate your business? Probably not. Plus a slider that has controls to move back and forth makes the page interactive, fun, and space-efficient.

4) It's okay that all the content is "above the fold" but do you think links to case studies are the best use of that space? Why not use it instead to guide clients immediately through your specific development process in simple terms, show them how easy it is to work with you, and show how you're different from competitors? Then you can give them a link to case studies to show that you practice as you preach.

5) "Cogeian Systems is a small team of custom software and web design experts." I'd be careful about your grammar. You're a small team of custom software? Oh wait, and web design experts. You could change that around a bit to be more clear and active, "Cogeian Systems' experts create custom software and web designs that meet your needs, affordably and on-time." Now your verbs are active, you're saying you have a team of experts, you say what kind of experts they are, and you share what the benefits are of having experts do the work (ie you save time and money).

<comment><USER19> Hey - thank you for posting all of this. While I have an eye for design, I'm not a UX or web designer so I don't usually have a ton of specific feedback other than knowing something doesn't look as good as other sites I work on.

I was hoping this would at least raise the question in his mind that maybe his site doesn't look that modern or professional. I've met a lot of business owners who are great at their business but not knowledgeable about web sites, and end up paying for a subpar product and not knowing it's low quality.

</comment></comment></comment><comment><USER21> I run budgeting for a reasonably large startup and ballparks are an easy way to understand if the ballpark of a consultant or SAAS software's costs is somewhat proportional to the pain point we are trying to solve.

If you are too shy to share how much you generally charge for your service, it means its going to be a big number, and there are fat sales margins in what you are selling. I'll pass.

</comment><comment><USER22> I think this article, while correct, really misses the boat on why offering ranges is so important. In a lot of cases, the wide-eyes dreamer client is the person who needs the most guidance on what something will cost.

My typical way of doing this is the same way I also give estimates of time or effort in software development: IF X is true, and IF y is constrained by z, then typically a project like this will be between $and $$.

Think of it as a qualification gate - before you're going to go through the time to scope out a project fully, does this person have the ability to make something at that price point happen?

Even more to the point, after you give them the ballpark, you should say, "if this project comes in somewhere in that general range, do you have the authority to sign off on this amount of money?"

Now you've not only potentially saved yourself some time, you've learned whether you're dealing with the decision maker here, or as some refer to it the "economic buyer"

Now, it's true, someone might say, "I want to build a social network for Journey fans that includes a live concert recording site", and yeah, that's too vague to scope something. But in those cases you scope it out as much as possible: "do you need chat? Is it mostly for sharing pictures? Is there a buy/sell aspect?", and then you put a floor on it:

"Well, we really need to spend a lot more time on this, but I would say something like this starts at X and goes up from there", where X is a large dollar value that you feel is 50% more than it would take to do the basic version of what they want.

But again, not giving ballparks is losing out on a great opportunity for you as a sales person to _control the deal progress_.

</comment><comment><USER23> The author has the tone of a consultant but gives the scenario of "If I charge you $10,000 to build a web app". On a budget of 10k to design and implement an entire webapp there is no money spare for a consultant.

Besides, anyone can easily work out a ball park figure: "I charge X per day. This project sounds like it is in the scale of multiple days/weeks/months. Therefore it will be in this rough range..."

This is pretty much how I respond to all business enquiries (I'm a freelance UX consultant). It cuts out a lot of time wasting.

Cached version of article: [http://webcache.googleusercontent.com/search?q=cache:S23YKe1...](http://webcache.googleusercontent.com/search?q=cache:S23YKe1OWcgJ:www.christopherhawkins.com/2016/05/ballpark- estimate/+&cd=1&hl=en&ct=clnk&gl=uk)

</comment><comment><USER24> I've been running a consultancy for quite some time, and I see where the author is coming from. We used to do things like that, and still insist on paid discovery sessions before giving actual quotes.

Here's the thing though. If you've been doing this for long enough, you already know how much your business WANTS it to cost. Are you the kind of contractor who typically does $100k deals? Then you're not going to take a $2k project. And your client should know that.

All they need to know is, will it cost $5k, $50k, or $500k? And be honest, you know what kind of budgets you need to build products if you've been doing this for long enough. If your projects range from "$50k to $300k", just say that, and it will move the conversation right along.

You will thank yourself later that you didn't spend a month working with a disqualified client.

</comment><comment><USER25> What I usually do is reverse the question. Since it's often times, very, very hard to ballpark things, I ask them what THEIR budget range is, and then let them know if what they're asking for falls inside of it.

If it doesn't, I offer up ways to make the project fall inside of it, or what parts of the project are so risky that, while in theory they might fall within, they might also blow up the budget.

Clients want ballparks because they need to know if pursuing a given project is worth their time. No one wants to spend hours putting together a project summary and working on detailed specs only to find is 2X or 3X more money than they have.

And the same is true for the agency. Why am I going to waste productive hours spec'ing something there's no way I'm going to actually book as work?

<comment><USER26> If you're a good an scrupulous contractor, you'll also be able to be able to tell them how much app you can build for them for the money they have available, which is completely valid for a client who needs something but has only a small budget. Often scope is negotiable, but your expertise will be important in helping define the scope.

</comment></comment><comment><USER27> I really despise smarmy sales talk like this. Why am I not surprised this is the consultant's website, apparently still written in ASP: [http://www.cogeian.com/index.asp](http://www.cogeian.com/index.asp)

</comment><comment><USER28> FTA: "If I charge you $10,000 to build a web app that saves or generate $50,000 of revenue, that project effectively cost you $0. But when you ask about cost up front, any answer I give you will just boil down to whether or not you feel like spending $10,000 today"

You are under the mistaken impression that as a software developer you are the only one in a this conversation that knows how much money a a particular task is worth automating. Here's a hint - not only do I know what it's worth to my business, but you probably don't. If you can't tell me if a job is in (a fairly wide) range of viability, then you're not likely to be a good partner for my business.

</comment><comment><USER29> The discovery session proposed seems to be just the thing to fill the gulf between what clients want (a reasonable ballpark estimate) and what the consultant is comfortable supplying...

While $1000 might be a little high, I think charging for that period of time where requirements are really chiseled out is the fix here... Then you can return after one of those meetings after doing some investigation with a hopefully somewhat reasonable estimate

<comment><USER3> Depending on your business and your services, $1,000 might be insanely low. (That's like 4-5 hours at a reasonable consulting rate... can you build out functional requirements in that time?)

The point is to give your client more data and an off-ramp, and works well for frank discussions (and ghosting your competitors):

"As you know, websites can be $1k or $1M. Based on this, I think you're in the $100k range. But until we get down into the details of exactly what you want to do, it's hard to say for sure, right? So I could do what a lot of firms do and bid $100k: if I'm high, I keep the difference. If I'm low, I surprise you with a change order. That's not how I do business. So if we're in the same range, let's start slow, figure out exactly what you want to do, not lock you into some giant contract with me, and give you better data to move forward with confidence."

</comment></comment><comment><USER30> It's part of the implicit negotiation to me. You get the other side to soft- commit to a given price range. A perfectly valid strategy. Not to say it can't backfire in a multitude of ways.

As a consultant you sometimes want them to do it too. For any sufficiently complex project the contractee doesn't have perfect knowledge of what they want either.

Actually I view articles like that as a part of a broader meta-negotiation.

</comment><comment><USER16> > and sharing coffee (which I will gladly spring for).

No. If the discovery session is $1000, I'm paying for that coffee. That cheeky attitude is why you are having issues with this and felt the need to blog about it.</comment>


Why Eiffel is my favorite language - <AUTHOR> http://www.advogato.org/article/1026.html <comment><USER2> Nit: This article is too new to be saying C# is "just java again". It started out that way but it's gone past java now in terms of functionality (e.g. closures, LINQ). The two look less and less alike with each passing version.</comment>


Djangae – Run Django on Google App Engine - <AUTHOR> https://p.ota.to/blog/2014/10/announcing-djangae/

<comment><USER2> There is not much love in the Django community towards web2py (to put it lightly), but if you are interested in Django on GAE it might be interesting to give web2py (for which GAE is a native backend) a look.

The main complaints against web2py are that it is "un pythonic" because it automatically imports some things for you (from Jacob Moss Kaplan / django), and that it re-executes scripts leading to some unavoidable memory leaks in some (arguably, non-idiomatic, easy to avoid and extremely rare) situations (from Armin Ronacher / flask). I hope I have properly summarized and not misrepresented the core arguments - apologies in advance if I did.

Having used both django and web2py for commercial uses, and helping newbies on the web2py list, I would say that these complaints have no practical significance. In my opinion, web2py is simpler and easier to use; and if you need GAE support, it's there.

</comment><comment><USER3> This has actually been done many years ago. [http://django- nonrel.org](http://django-nonrel.org) . Don't know how it differs from this one, but it has many of the same features. Used it for a project 4 years ago.

How is performance compared to using cloud sql ?

<comment><USER4> Yeah, we used Django-nonrel and Djangoappengine for a long time, and Djangae is heavily inspired by it. However the advantage that Djangae has is that it works with normal Django - it doesn't require a patched fork like djangoappengine.

As for performance, it depends what you are doing. Obviously the datastore is non-relational so it scales much better with a lot of data, and you don't have to deal with things like migrations or connection limits. But then you can't do complex queries and aggregates etc. the good thing about using Djangae is you can make use of Django's multiple database connections to store your data in whichever form makes sense (datastore or CloudSQL).

</comment></comment><comment><USER5> that is a nice development and google should give some support or contribution for that.

It does reduce the barrier to use Django in AppEngine and does remove the need for the cloudsql db instance(mysql)

</comment><comment><USER6> Is there any benefit to using the Datastore, as opposed to CloudSQL?

<comment><USER4> There are many benefits, depending on your situation. If your website is expected to get a high QPS, or you have a lot of data (e.g. millions of rows) then using the datastore can be much more suitable (you don't have to deal with schema migrations or connection limits etc.)

You, of course, have to put much more thought into the model design on the datastore and your design should play to the strengths of a non-relational store but once you have that right your site will seamlessly scale.

But CloudSQL is also more suitable in many situations, there are no aggregates or joins on the datastore. You need to to pick and choose the right technology for what you are doing.

Djangae is awesome here, because you use a consistent API for both CloudSQL and the Datastore, which makes switching between the two much easier.

</comment></comment><comment><USER7> I haven't used either approach, but how does using this project compare to just using NDB directly with the Django middleware?

[https://cloud.google.com/appengine/docs/python/ndb/#integrat...](https://cloud.google.com/appengine/docs/python/ndb/#integration)

<comment><USER8> Djangae lets you use the Django ORM with the Datastore, meaning you don't have to use NDB. It also has lots of other helpers for things like deferred tasks.

The Django NDB middleware written by Google, as far as I can work out, just makes sure that writes are flushed. You still have to define and query your models using NDB syntax.

</comment></comment><comment><USER9> What django version is this based on? Some of the other nonrel projects that I'm aware of are based on the LTS 1.4 (LTS until next year), and haven't really progressed from there.

<comment><USER4> 1.6 is supported in the alpha, we're aiming for 1.7 support before beta. From that point on we intend to support the two most recent stable Django releases.

We structured the Djangae database connector to be as de-coupled from Django as possible (everything happens at the cursor level) so hopefully keeping up with Django releases should be fairly easy (hopefully!).

</comment></comment><comment><USER10> As Django developer for over 6 years, sorry guys I don't see the benefits of hacking the framework in this case. I know so many people love django out there and try to apply it as much as they can. When you think you go with the- easy-thing, you're going to make it harder.

BTW, depending on the purpose, I will go with another frameworks, even another languages.

</comment><comment><USER11> I'm just disappointed this isn't called "Djangoogle"

<comment><USER12> I tried very hard to persuade them to call it "Djappango", but no dice.

</comment></comment><comment><USER13> Anybody else read this as "Djan-gay?"

<comment><USER12> I believe the official pronunciation is /ˈdʒæŋɡiː/ ("djan-gee").</comment></comment>


Show HN: Buy a new domain name and host it with one API call - <AUTHOR> https://picnic.sh/api

<comment><AUTHOR> We just launched our API and would love your thoughts. Last week we launched Picnic.sh (PH thread [http://www.producthunt.com/posts/picnic](http://www.producthunt.com/posts/picnic)) to try and make it a lot easier and cheaper to set up one-page domain names.

Today we are opening up our API beta. We're hoping people will find a lot of use for this for things like resumes, about pages, app landing pages, etc ...

Thanks!

</comment><comment><USER2> This is pretty cool for projects where I want to register the domain, but don't have any content yet.

But once I'm ready to move to my own server, there should be a way to update DNS records (and manage renewals).

I wish this were a feature of an existing registrar, than a product itself.

</comment><comment><USER3> Wow, excellent idea.</comment>


Remove unwanted objects from photo (Open source, C#) - <AUTHOR> https://github.com/zavolokas/Inpainting <comment><USER2> Is there an executable? Is this a command line program?</comment>


Fukushima: It's much worse than you think - <AUTHOR> http://english.aljazeera.net/indepth/features/2011/06/201161664828302638.html <comment><USER2> "In the US, physician Janette Sherman MD and epidemiologist Joseph Mangano published an essay shedding light on a 35 per cent spike in infant mortality in northwest cities that occurred after the Fukushima meltdown, and may well be the result of fallout from the stricken nuclear plant."

"The eight cities included in the report are San Jose, Berkeley, San Francisco, Sacramento, Santa Cruz, Portland, Seattle, and Boise, and the time frame of the report included the ten weeks immediately following the disaster."

I tried to source this on Google. I can't find the article by Sherman and Mangano, but found this discussion:

<http://www.nuc.berkeley.edu/node/4550>

It appears the authors cited by AJE were using CDC data. Someone posts the infant death numbers at the Berkeley link. The numbers are very small with a lot of deviation. And it's not clear that they're even being measured against total number of births.

I've heard a lot of praise for AJE's reporting and I wouldn't be surprised to learn that TEPCO and the Japanese government were continuing to understate the risk, but this article seems shoddy and sensationalistic.

<comment><USER3> I was very surprised to see statistics like that so soon after it happened. Typically reliable statistics for data like infant mortality are not available until awhile (read: a year) after the event.

And, frankly, even then it seems very early to draw a conclusive connection to Fukushima. Correlation != causation.

</comment></comment><comment><USER4> "In the US, physician Janette Sherman MD and epidemiologist Joseph Mangano published an essay shedding light on a 35 per cent spike in infant mortality in northwest cities that occurred after the Fukushima meltdown, and may well be the result of fallout from the stricken nuclear plant."

Somehow, I'm not surprised by this. Janette Sherman is an anti-nuclear activist:

<http://janettesherman.com/>

Joseph Mangano is the director of the "Radiation and Public Health Project":

<http://www.radiation.org/>

They are not exactly disinterested parties, and it is fair to say that their article would never be published in a peer reviewed journal:

<http://www.counterpunch.org/sherman06102011.html>

Side Note: This is not the most scientific graph in the world, but (in the event of another panicked radiation article) it is always worth linking to the xkcd graph on radiation:

<http://xkcd.com/radiation/>

<comment><USER5> Isn't this the kind of argument that Paul Graham charcterizes as "ad hominem" and usually gets voted down on Hacker News?

Don't get me wrong, personally I think it's very valid to bring up and important to keep in mind while reading their article. But it seems like a double standard to me.

<comment><USER6> Motive is incredibly important. Saying someone has a reason to be biased is not ad hominem. Saying they're a fucking hippie is.

<comment><USER7> It's absolutely an ad hominem and a logical fallacy. The study itself is given. We can evaluate it without any knowledge whatsoever of the authors. The only time such a claim is not an ad hominem is when the target of the ad hominem is arguing from authority rather than from facts.

Not ad hominem: "I'm a godlike scientist and I'm certain X is true. Trust me." -> "No, he's a poopie head. Don't trust him."

In this case, the only reason we believe the speaker is because we believe him to be a godlike scientist. If he is not, we have little reason to believe him.

Ad hominem: "Here is a study. The methodology and data are available. It claims X." -> "Don't trust him, he's a poopie head."

In this case, the poopie-headed nature of the speaker is irrelevant. His methodology is either valid or invalid. The ad hominem attack is a logical fallacy in this case.

</comment></comment></comment></comment><comment><USER8> _In the US, physician Janette Sherman MD and epidemiologist Joseph Mangano published an essay shedding light on a 35 per cent spike in infant mortality in northwest cities that occurred after the Fukushima meltdown, and may well be the result of fallout from the stricken nuclear plant._

 _The eight cities included in the report are San Jose, Berkeley, San Francisco, Sacramento, Santa Cruz, Portland, Seattle, and Boise, and the time frame of the report included the ten weeks immediately following the disaster._

I don't know why anyone should take this article seriously. Here's the thing about radiation: We can measure it directly. And scientists have certainly been able to measure radioactivity here in the U.S. that must be a consequence of Fukushima. But here's the thing: those radioactive effects -- here in the U.S. -- are very, very small.

<comment><USER9> Indeed. Berkeley's nuclear engineering department has been running one of the better monitoring programs:

<http://www.nuc.berkeley.edu/UCBAirSampling>

</comment></comment><comment><USER10> There's a lot of nonsense in that article. First of all, they keep repeating the words Plutonium and Uranium (particularly "enriched Uranium") and try to suggest that these are the major threats from the accident.

They're not.

Uranium isotopes have a half-life of billions of years, so whatever radioactivity they emit is spread out over a very long time. Overall, uranium is toxic in the same way that lead is toxic, and the chemical toxicity is probably worse than the radiotoxicity. Even in a completely melted reactor core, uranium dioxide is relativly stable and won't be quickly transported into the environment.

The isotopes of concern are primarily of Iodine and Cesium. Radioiodine from the accident has almost completely decayed, although Cesium isotopes may still be hazardous in heavily contaminated areas for years.

Currently there seem to be "hotspots" at considerable distances from the plant where doses on the ground are in a range that's at the edge of what nuclear power workers are permitted to get (but rarely do.) There's no proof that radiation at that level is harmful, but no proof that it's completely safe to have that exposure for your lifetime either.

Now, it's also BS to say that the threat from spent nuclear fuel that's been sitting around for 10 years is as high as the threat from an active core or one that's been sitting around for three months -- it just isn't; radioactivity decays and heat generation goes down, so it's really unfair to count the number of "cores" worth of danger here.

That said, I wouldn't blame people for mistrusting Japanese government, industry and even society. Japan has been the world's leader in nuclear accidents for the past 20 years, and it's often said that they're not completely honest about industrial accidents in general (such as in the auto industry.)

Nuclear safety requires a person who's disciplined and (for the most part) follows orders but who also has a strong individual sense of right and wrong and won't follow a bad order. America's nuclear navy works hard to cultivate this ethos, but I'm not sure if it's easy to cultivate this in Japan.

<comment><USER11> _Overall, uranium is toxic in the same way that lead is toxic, and the chemical toxicity is probably worse than the radiotoxicity._

You know darn well we're not talking about "overall uranium".

We're talking about very hot uranium and plutonium directly from the cores of active nuclear reactors and the entire spectrum of elements and isotopes that get produced when you take that core, rods, and support structure and melt it out through the bottom of a containment vessel onto a concrete foundation that wasn't designed as a core catcher. Mix in seawater, steam, hydrogen explosions and gord knows what else and you have a reaction that is insufficiently modeled.

What we do know is that a large area of land is not being occupied in Japan due to contamination. The Japanese have very expensive land, know a thing or two about radioactive contamination, and are not exactly known for exaggerating the impact of industrial accidents.

<comment><USER12> The uranium in that reactor isn't different from overall uranium, except that it's concentrated and its composition differs from what naturally occurs. However, that's _over there_. Uranium would be dangerous to US citizens if the uranium was _in the US_. It isn't. And so far, not even the worst doomsayers that actually know their stuff have worried about uranium or plutonium. That's just not the stuff you care about after a nuclear meltdown. You care about the other isotopes that were produced and that are much more easily carried outside and are easily used to compose other molecules that can spread further.

Secondly, what on earth is 'hot uranium'? If you are speaking about the temperature: it certainly isn't hot anymore by the time it reaches the US. If you are speaking about it's radioactivity, you're wrong: individual uranium atoms from that reactor, once escaped, do not behave differently than naturally occurring uranium atoms.

As for your other fears: it's perfectly well known what radioactive isotopes controlled and uncontrolled fission processes can produce. That's why they've been monitoring for things like cesium, iodine and basically every radioactive isotopes that exists: the number is rather limited). No significant levels of the stuff have been seen in the US.

<comment><USER11> _The uranium in that reactor isn't different from overall uranium, except that it's concentrated and its composition differs from what naturally occurs._

That can be a pretty serious categorical difference, particularly in the concentration.

 _However, that's over there. Uranium would be dangerous to US citizens if the uranium was in the US. It isn't._

Duh.

Did you even read what I wrote or are you pasting this from some talking points you got somewhere?

 _And so far, not even the worst doomsayers that actually know their stuff have worried about uranium or plutonium._

Which is not to say it's not a problem, only that you find some reason to dismiss the views you don't agree with.

 _That's just not the stuff you care about after a nuclear meltdown. You care about the other isotopes that were produced and that are much more easily carried outside and are easily used to compose other molecules that can spread further._

That must be why they're setting limits on the acceptable level of uranium in the rice then. To draw attention away from the things that are really dangerous. [http://www.businessweek.com/news/2011-03-28/fukushima-may- ab...](http://www.businessweek.com/news/2011-03-28/fukushima-may-abandon-rice- planting-amid-radiation-in-soil.html) Riiight.

 _Secondly, what on earth is 'hot uranium'?_

What I said was "very hot uranium and plutonium directly from the cores of active nuclear reactors and the entire spectrum of elements and isotopes that get produced when ...".

 _If you are speaking about the temperature: it certainly isn't hot anymore by the time it reaches the US. If you are speaking about it's radioactivity,_

In this case, the term 'hot' captures temperature (in Celsius), reactivity (neutrons), and the health effects of radioactivity (Becquerels). It works on many levels.

 _you're wrong: individual uranium atoms from that reactor, once escaped, do not behave differently than naturally occurring uranium atoms._

You really seem to want me to be talking about specifically uranium atoms in fallout on the continental US. The vast majority of that article is about Japan with only a few sentences claiming some nonspecific particles could be detected in the US.

Is it that you know only this one counter argument, the one that natural and low-enriched uranium samples aren't wildly different in decay rates?

 _As for your other fears:_

I'm not afraid, you're just making that up.

 _it's perfectly well known what radioactive isotopes controlled and uncontrolled fission processes can produce._

I don't think our knowledge of these meltdowns is anywhere close to "perfect", but note that I said "the entire spectrum of elements and isotopes...".

They don't know what temperatures were reached what state of matter the cores were in and for what time periods. The IAEA says there could have been recriticality, but they don't know for sure one way or the other.

 _That's why they've been monitoring for things like cesium, iodine and basically every radioactive isotopes that exists: the number is rather limited)._

Do you think I've never heard of the periodic table or something?

</comment></comment></comment></comment><comment><USER13> The quick onslaught of the "it couldn't possibly be a meltdown" message in the mainstream media and the "MIT professor says" emails/webpages, etc all smacked of a propaganda campaign to me. All the while the fuel rods were sitting in a puddle at the bottom of the reactor... and probably leaking through into the ground.

Of course, it's more likely that it was a lot of people not willing to believe the scope of the catastrophe than a conspiracy to suppress information, but the forcefulness of the response was striking.

I heard a great (and probably apocryphal) anecdote on the radio a few weeks after -- "After three mile island, the Russians came to the US, performed a detailed analysis, and concluded 'we can't have a three mile island'. Instead, they had a Chernobyl. The Japanese went to Russia, did an analysis, and said 'we can't possibly have a Chernobyl', and instead had their own meltdown. Now we're hearing how modern reactors couldn't possibly have a meltdown like any of three so far."

<comment><USER14> I was shocked at the immediate "this is not a problem" reaction by many people -- particularly here at Hacker News.

<comment><USER15> Just think of it as a natural counterweight to all the people who equate meltdown with a nuclear explosion.

<comment><USER16> Where are such people? From my perspective, you're suggesting a natural counterweight to nobody.

<comment><USER17> Where are the "this is not a problem" people? I dont' recall a single person claiming the failure at the plant wasn't a problem. As I recall it, there was a "this is not Chernobyl" camp.

<comment><USER18> There were both. The HN (and "MIT") response was particularly disturbing to me. You couldn't question the official reports of "everything is fine and under control" around here without getting completely slammed, belittled, berated, downvoted, etc.

And yet now we know that the total radiation release was probably as much or more than Chernobyl.

What I said at the very beginning of this disaster.. If there's one thing everyone should know by now about nuclear reactor emergencies - it's that the authorities never tell the truth in the beginning, through ignorance or otherwise. We have an admittedly small sample of such accidents, but I'm sticking with it.

<comment><USER19> > And yet now we know that the total radiation release was probably as much or > more than Chernobyl.

We do? Evidence, please.

For what I think is the conventional view, see e.g. <http://www.bbc.co.uk/news/world-asia-pacific-13050228> which indicates more than 10x more radiation release from Chernobyl. That was a couple of months ago; has the situation changed drastically since then?

(On 2011-04-12, when the incident was reclassified at IAEA level 7, a TEPCO spokesman made some comment about the Fukushima disaster having released more radiation than the Chernobyl one. I'm pretty sure that was simply not true.)

I think the "MIT" response was basically correct and remains so despite scaremongering like that linked to here. The Fukushima plant was hit by an enormous natural disaster; yes, the results were very bad, but they were very much smaller in both human and economic terms than those of the earthquake+tsunami itself and so far the known death toll (due to radiation as opposed to, e.g., things falling on people's heads) from the damage to the nuclear reactors is ... zero.

That doesn't mean the damage isn't a problem, it doesn't even mean it's not a disaster. It does, however, mean this: A large, aging nuclear facility was struck by a huge natural disaster, much worse than it was ever designed for (which was, yes, a Bad Thing) -- and the result, so far at least, has not involved death or disease on a large scale.

If that's as bad as the downside of nuclear power gets, it's looking pretty good.

(What's the downside of the alternative? Well, imagine that the Fukushima reactors hadn't been built and that the energy they provided had come from coal-fired power stations instead. Generating energy from coal costs about 15 deaths per TWh in the US, according to [http://nextbigfuture.com/2011/03/deaths-per-twh-by-energy- so...](http://nextbigfuture.com/2011/03/deaths-per-twh-by-energy-source.html); Japan is probably similar. The Fukushima plant produced a bit less than 880 TWh of energy over its lifetime. That's about 13,000 deaths. Even with the disaster, there's no way that the Fukushima plant has caused anything near to that many.)

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> I love AJE, but I'm regularly surprised over the amount of balls AJE reporters have in making value judgements on the fly. For instance:

 _Why have alarms not been sounded about radiation exposure in the US?

Nuclear operator Exelon Corporation has been among Barack Obama's biggest campaign donors, and is one of the largest employers in Illinois where Obama was senator. Exelon has donated more than $269,000 to his political campaigns, thus far. Obama also appointed Exelon CEO John Rowe to his Blue Ribbon Commission on America's Nuclear Future._

<comment><USER21> On the flip side, I'm regularly impressed by how the US media almost _never_ questions, mentions or takes note any of the money and power connections which influence US politics so heavily.

I think the story is deeper than one company who gave $269,000 however.

<comment><USER22> The solution is to find higher quality news outlets. NPR and PBS come to mind.

<comment><USER21> While they, along with the New Yorker, Vanity Fair, Rolling Stone and a few other magazines are better than average, they still don't question things in the way I'd like. There's still plenty things that seem to be unspeakable in their journalism.

</comment></comment></comment></comment><comment><USER23> "Most of the reactors in Japan were designed by US companies who did not care for the effects of earthquakes,"

As an Engineer I call bullshit on this.

<comment><USER14> Around the time of the disaster there were stories about a GE engineer who resigned in protest in 1970 over this particular model of reactor.

If I recall correctly, the engineering team's concerns about fail-safes in the event of a loss of electrical power were overruled or dismissed.

<comment><USER24> The potential problems resulting from loss of electrical power were and are well understood. What happened in Fukushima wasn't a flaw in the reactor design - it was a flaw in the design of the power station.

<comment><USER14> It's a flaw in the system. A system built around a reactor with known risks if electrical supplies are interrupted.

This is a region of a country where tectonic activity is significant enough that seaside villages are cutoff from the sea by 15 foot reinforced walls.

A reactor with the failure characteristics of the Fukushima reactors sound like the wrong tool for the job to me.

</comment></comment></comment></comment><comment><USER25> I'm not a big fan of the automatic approval many on HN give to nuclear power, and I agree that we haven't heard the last of Fukushima.

But this article is bullshit. There is no conceivable mechanism for it to have occurred, and no pattern in other cases of nuclear exposure.

</comment><comment><USER26> One disaster, and people forget the half century of prosperity that nuclear power brought. Worse, the general public is going to see Fusion (fingers crossed) in the same way as fission just because it's also "nuclear power". I'm disheartened.

<comment><USER27> Uh, yeah, I mean, these are human being we're talking about. We can't even get people to accept evolutionary theory. I won't hold my breath waiting for people to be even-handed and partake in critical thought about the vagaries of nuclear power.

</comment></comment><comment><USER28> "'Fukushima is the biggest industrial catastrophe in the history of mankind,' Arnold Gundersen, a former nuclear industry senior vice president, told Al Jazeera"

OK, after reading the first sentence, I was already suspicious of this article. Quick tab back to HN comments seems to confirm it. Thanks for saving my time, HN.

<comment><USER29> I have to wonder why he ranked it above Bhopal, Deepwater Horizon, or even Chernobyl. Chernobyl had burning graphite and a fully exposed core. There were also lots of people dying of radiation sickness.

Thankfully, none of the plant workers appear to have died from that, though they have more reason to fear overexposure than anyone.

<comment><USER30> Interestingly, a documentary I saw on the on-site group studying Chernobyl mentioned that most of the group died prematurely, but not of radiation sickness or cancer. They died of heart failures and stress-induced health problems.

A long time afterwards, some of the survivors saw non-terminal cell damage related problems.

</comment></comment></comment><comment><USER31> Fukushima is a disaster, yes, but this article (particularly the little subsection blaming the USA) is full of appeals to emotion.

</comment><comment><USER32> It will be interesting to see if, in a few years, dentists and doctors start collecting baby teeth, which can then be analyzed for uptake of radioactive materials into bone.

This was done in the 50s and 60s in the USA - the large number of above-ground nuclear tests put material in the air, which was detectable in teeth from children living at that time.

(link may be biased against nuclear but contains overview of the study): <http://www.radiation.org/projects/tooth_fairy.html>

</comment><comment><USER33> No it's not. The long-term environmental impact from fukushima is _far_ smaller than that from the BP oil leak last year. The extra radiation being received by people who live a _mile_ from the site is on par with eating two bananas every day.

The impact isn't nothing; this is a significant catastrophe. But that article is sensational bullshit.

</comment><comment><USER34> This article really lowers my opinion of Al Jazeera english.

<comment><USER35> I read/watch AJ English most days and I've found that their on-the-ground reporting is excellent but they also publish a lot of marginal rubbish.

</comment></comment><comment><USER36> From the article, it seems as though experts are saying the design of the reactors by GE didn't take into account that Japan has earthquakes.

GE was never named directly, but wikipedia says it was their design. [http://en.wikipedia.org/wiki/Fukushima_Daiichi_Nuclear_Power...](http://en.wikipedia.org/wiki/Fukushima_Daiichi_Nuclear_Power_Plant)

<comment><USER11> AFAICT the plants reacted to and withstood the earthquakes fairly well. The tsunami on the other hand...well I guess nuke plants and 14 meter high walls of water don't mix.

<comment><USER37> I believe the main problem wasn't the damage to the plants so much as the loss of power and unreliability of backup power, a known and critical flaw in an earthquake-prone area.

<comment><USER11> The term "plant" includes all the surrounding equipment. Batteries, backup generators, fuel reserves, etc.

My understanding is that if a functioning subset of generators had survived they could have powered the cooling pumps and the problem would have just been keeping them refueled. You can truck-in or airlift-in fuel quicky, so this would have been a very manageable problem in the short and medium terms, much more so than repairing long spans of downed electrical distribution lines.

</comment></comment></comment></comment><comment><USER38> What exactly are "hot" particles that can't be measured with a Geiger counter? I assume they are talking about radioactive particles and not particles with increased temperature. This article sounds like pseudo science to me.

</comment><comment><USER39> If our best scientific assessments are based on absurdly low-confidence ancillary statistics like these, doesn't that automatically suggest that we shouldn't decide anything based on the results?

</comment><comment><USER40> In addition to the other criticism.

From the article: _TEPCO announced that the accident probably released more radioactive material into the environment than Chernobyl, making it the worst nuclear accident on record._

Is there a reference supporting this? I've only seen values for Fukushima radiation as a fraction of Chernobyl (and if I remember correctly, not as bad isotopes)?

A while ago, I got multiple comments modded to -10, for questioning the trustworthiness of Al Jazeera. The web site is not connected to the tv channel?

(For the record: I don't really know about al J. I distrust most media, except NY Times/Washington Post/BBC as long as they don't write about advertisers.)

<comment><USER41> With zero effort, I found this for you:

[http://www.yomiuri.co.jp/dy/national/T110413005584.htm<b...](http://www.yomiuri.co.jp/dy/national/T110413005584.htm<br/>);

"Junichi Matsumoto, acting head of Tokyo Electric Power Co.'s Nuclear Power & Plant Siting Division, acknowledged the seriousness of the Fukushima accident at a press conference Tuesday. 'Although the details of the [Chernobyl and Fukushima] accidents are different, from the standpoint of how much radiation has been released, [Fukushima] is equal to or more serious than Chernobyl.'"

That was just a citation in the Wikipedia page for the incident.

<comment><USER42> Could they be referring to the INES disaster scale, on which Fukushima rates equal to Chernobyl?

Also, the direct release of radiation from the reactor is significantly less serious than the release of certain radioisotopes. If they're only comparing absolute radiation levels, and (hypothetically) most of Chernobyl's was in radioactive cesium, while most of Fukushima's was in alpha/beta/gamma particles or short-lived radioactive oxygen/nitrogen/etc., then the comparison is not very useful.</comment></comment></comment>


Enough of Upwork Shit - <AUTHOR> When you are the largest in the market or have monopoly in the market, there is nothing you can't do. You can:
Charge excessively high prices Force down the fair price of a gig to less than minimum wages Block people's access to their own hard earned money Stop taking new accounts Scam your clients and customers Abandon existing contracts by blocking clients or freelancers Violate your own policies Force to use a bad service on high price Apply algorithms to scam more people and make more money Exploit clients and freelancers by imposing highest commission Block anyone who raises voice Stop providing actual customer service Stop giving sh That is exactly what the gig economy giant upwork.com is doing since a long time. Online freelancing communities and chat rooms are full of people upwork has exploited and robbed. Few references:
https://www.sitejabber.com/reviews/www.upwork.com http://upworkfraud.byethost4.com/?i=1 https://hackernoon.com/why-you-should-never-use-upwork-ever-5c62848bdf46 https://www.quora.com/What-is-your-review-of-Upwork
Seasoned freelancers would know what an apocalyptic change it has taken since it became Upwork. There is no more trust; there is no more genuineness, no more professionalism. It has become a wild wild west.
Upwork is a greedy marketplace that only tries to make more money for itself. Sky touching commission and service charge is not enough so they started blocking people to access or withdraw their own money.
We propose the solution
You get to know how you can fix a problem when you have faced it for several years. That's how all issues you face in freelancing has been fixed by us. All these problems needed to be resolved but never seemed to be. Then the concept of resolving them born.
Toogit.com
Toogit born to solve these issues. Not to make money, but to make freelancing better and transparent than ever. <comment><AUTHOR> To learn more check out this link -> [https://www.toogit.com/blog/post/why- toogit-is-best-upwork-a...](https://www.toogit.com/blog/post/why-toogit-is- best-upwork-alternative-even-better-than-upwork)

</comment><comment><USER2> Toogit, is that git like jit or git? What does it mean? Is that an Indian word?</comment>


WeWork Bans Meat - <AUTHOR> https://sfgate.com/business/article/WeWork-tells-employees-meat-is-permanently-off-13073731.php <comment><USER2> duplicate: [https://news.ycombinator.com/item?id=17526695](https://news.ycombinator.com/item?id=17526695)

also some here: [https://news.ycombinator.com/item?id=17524534](https://news.ycombinator.com/item?id=17524534)

</comment><comment> core-questions This is kind of insane, even by virtue-signalling standards.

What business is it of the company what kind of food I eat? Alcohol restrictions make enough sense, but beyond that how is it at all reasonable to place these kinds of restrictions on their employees, especially when traveling for business? Some cities simply don't cater to the vegan market on a large scale. Sometimes you don't have as much of a choice what restaurant you're going to.

How will they even know what you ate? Receipts from restaurants often don't have that much detail. Are their Accounts Payable people going to scrutinize every receipt and google it up to determine if it's vegan compliant?

All I know is that if I'm looking for coworking space, it ain't gonna be from these guys.

<comment><USER3> > _What business is it of the company what kind of food I eat?_

They aren't policing employees' eating habits or anyone else's. They've just decided not to spend company funds on meat.

There are valid social, political, and environmental reasons to avoid most or all meat. A company should be able to decide not to spend their money on something both ethical and socially beneficial that won't harm anyone else in the process.

> _How will they even know what you ate?_

Some restaurants have line items, but most likely this is a marketing tactic more than a rigid policy that will be easily or thoroughly enforced.

> _Some cities simply don 't cater to the vegan market on a large scale. > Sometimes you don't have as much of a choice what restaurant you're going > to._

Where did you get vegan? They seem to be allowing expensing of vegetarian food.

And when do people not get to choose where they eat? And when they do, why would it be a place that serves zero vegetarian options?

Also, they seem to be pursuing a pescetarian policy (no mammals or birds, but fish are OK).

<comment><USER4> There are not valid environment or social reasons to avoid meat.

Cattle is the most efficient way to produce calories in a dry region in which water rather than land is the binding constraint (Western U.S., middle east, north africa). Crops are the most efficient way to produce calories in regions where land rather than water is the binding constraint (e.g. China, Northwest Europe).

The idea that one is necessarily more efficient than the other _as a food_ is pure B.S. It just depends on where that food is grown.

There is a reason why the societies in the fertile crescent began with cattle culture, and continued to raise cattle in areas where water is more costly than land. Dry areas like that produce scrub and grasses, which is inedible to humans, but edible by cows. That's why we graze the cows in areas where we can't eat the natural crops, and instead we eat the cows. This is the most efficient method, most environmentally friendly method, and is the long standing practice of all societies living in dry regions.

This notion that the peculiar environment constraints that bind in northwest europe bind globally is either ignorance or bigotry.

Really, if they wanted to virtue signal, they should ban cotton, which takes up a lot of water, and is grown in areas that shouldn't be growing cotton. As good a case can be made against grains as against cattle.

This is just bumper sticker virtue signalling and has no place in the business world.

<comment><USER5> WeWork doesn't operate in the (noncoastal) western US, so your argument is irrelevant to them. Most of us don't live in ancie Mesopotamia anymore. WeWork employees aren't expensing meals at Montana ranches.

<comment><USER4> 1\. Almost all of the entire entire Western U.S. (including most of california) is an arid area. It used to be called "The Great American desert". For more information, I'd recommend reading "Cadillac Desert" 2\. Where WeWork is headquartered is not the point. The point is the notion that meat is bad stems of a view of the entire world having a certain climate where growing meat has much higher opportunity costs. Once we recognize that we do not live in a world like that, we can hopefully move on from these types of myths.

</comment></comment></comment></comment></comment><comment><USER6> > The startup has told its 6,000 global workers that they will no longer be > able to expense meals including meat, and that it won't pay for any red > meat, poultry or pork at WeWork events

Title seems to be clickbaity -- they aren't _banning_ meat, they are just no longer subsidizing it.

</comment><comment><USER7> This seems to be a "startup PR act": they had to find some "new cool thing" to make people talk about them, that's what WeWork do, that's what most startups do.

It's not about money, it's not about virtue: they could as well have made flamethrowers or a tiny submarine or put ping-pong tables everywhere. It's a media distraction: everyone is focused on this now, and not on the real goal/activities (or finances) of the company.

Good PR job.

</comment><comment><USER8> Mic the Vegan just released a relevant [1] video today called "The Real Cost of Meat" [2]

[1] it isn't clear to me that WeWork did this for cost or ideals, but I thought I'd share in any case

[2] [https://youtu.be/tA9f2JU5bRs](https://youtu.be/tA9f2JU5bRs)

</comment><comment><USER8> This policy aside, I think it's strange that fish is not considered meat...

<comment><USER9> <sarcasm>They may have some Catholics sitting on their board</sarcasm>

</comment></comment><comment><USER10> I'm allergic to legumes and diabetic... WeWork can go to hell.

<comment><USER11> WeWork is just saying they won't pay expenses on meat. They're not banning anyone from eating meat.

<comment><USER12> So they're just financially penalizing people that do

<comment><USER11> Nobody is telling WeWork employees they need to eat meat while traveling. Lots of places prohibit the expensing of alcohol.

</comment></comment></comment></comment><comment><USER12> Has anyone done the back of the envelope math on this? If you send an employee across the country and stop them from eating meat, does that offset the environmental damage of their flight?

<comment><USER13> This doesn't hold up at all.

Cross country flight: .61 metric tons = 1344 lbs ([https://calculator.carbonfootprint.com/calculator.aspx](https://calculator.carbonfootprint.com/calculator.aspx) )

1 hamburger: 4 lbs ([http://www.businessinsider.com/one-hamburger-environment- res...](http://www.businessinsider.com/one-hamburger-environment- resources-2015-2) )

So, one flight is 336 hamburgers (in terms of CO2).

</comment></comment><comment><USER5> Shaking out all the rabid anti-vegetarianists might who kneejerk response with seething hatred and without reading, might enough of the business benefit to overcome any costs of this policy.</comment>


SQL Databases Don't Scale - <AUTHOR> http://adam.heroku.com/past/2009/7/6/sql_databases_dont_scale/ <comment><USER2> Can we please stop with these ridiculous "SQL is utterly hopeless" and SQL vs NoSQL articles? Saying that SQL is not scalable, full stop, is ignoring decades of real-world evidence. There's a right tool for every job, and SQL isn't always that tool, but articles like this aren't helpful in the slightest.

</comment><comment><USER3> I think TFA gets it all wrong.

It's not that SQL databases do not scale _per se_ , they just can't arbitrarily scale.

Most applications today manage pretty well with nothing more than sharding and replication. Sure, it's not the optimal solution, and it's not easy - but it gets the job done.

Facebook, at the very core (behind all the layers of cache), run, arguably, the largest MySQL landscape in the world - and they seem to be doing pretty good.

Until Heroku comes up with a better solution (or a better question), TFA is no more than flamebait.

<comment><USER4> "It's not that SQL databases do not scale per se, they just can't arbitrarily scale."

Tell that to Clustrix, Vertica, and VoltDB.

SQL is a query language, Relational is a data model, neither one prevents scaling out.

<comment><USER3> I was merely using the same terminology as the article.

</comment></comment></comment><comment><USER5> I can't count how many Rails fanboys have written this same article. What do they think big companies, banks, government agencies -- organizations with huge databases -- use? What kind of database do the RoR developers think the real world runs on?

Claiming that SQL databases don't scale, especially using MySQL as the example, is simply ignorant. Oracle, DB2, SQL Server all scale to handle databases orders of magnitude bigger than anything the most successful RoR app is running.

<comment><USER6> Well, they don't scale indefinitely, and you do run in to Brewers Theorem at some point. While you're right in saying that if you have enough cash and horsepower to throw at SQL databases you can get a very long way, there is some point where anything which must be consistent is going to have an impact on availability.

This gets especially critical once you stop assuming that data can be centralised. Once your required transactional context needs to scale large areas (geographically or logically) then the overhead of this is mighty. 2PC itself does not scale indefinitely, and while interesting research is being done in alternative transactional approaches, it would be tough to argue that any are acceptable solutions to the problem.

Also your example of banks is perhaps not an ideal one. While banks may indeed run some very large databases, they don't run one HUGE database which is expected to be always consistent. Things like ATM systems etc. run based on eventual consistency and tolerance favouring availability precisely because a simple horespower approach to a transactional database (whether SQL or not) wouldn't currently work in this domain.

<comment><USER5> Nothing scales indefinitely, not even RoR. But that wasn't what the article complained about. If the author had written "SQL Databases Don't Scale Indefinitely" I wouldn't have any complaint about it.

My point is that there are plenty of real-world examples of SQL databases that are scaled way beyond any RoR web app's needs, so flatly claiming they don't scale is wrong.

The solution banks (and other large organizations) have arrived at -- using multiple databases with different transactional and availability requirements -- IS a solution to scaling large databases. There's no requirement that SQL databases be monolithic. Even the original article describes using a MySQL master for updates and one or more slaves for reads. That's a valid scalability solution if your application can live with the possibility of stale data in the slaves.

</comment></comment></comment><comment><USER7> Wow, a lot of dislike of SQL, and a bit biased in their description of scaling SQL and sharding. Again, use the right tool for the right purpose, not what you think is intrinsically better.

Our app does double entry accounting, and considering the relational structure of accounting ledgers as well as that every entry needs to be posted in an ACID manner, we don't feel comfortable building out, say, a banking system in NoSQL.

Yes, SQL is painful to scale, but it can be manageable. We partition it in a scoped schema way (e.g each company account/tenant has its own set of tables on one of the shards with the server of the fewest consumed resources, or if it's a tie, a coin toss). Scaling it in an arbitrary manner such as by names beginning A to M, N to Q, etc simply seems like a bad way to do it. If your app is like a 37 Signals app where it doesn't typically require access to another account's data, this might be a good way to do it.

One of the programmers I hired was dead set on trying to use CouchDB for everything. I told him don't try to use it for everything--it's good to use for the audit trail and document revisions on invoices, orders, etc, but not on actual double entry journals.

</comment><comment><USER8> The #1 way to get relational databases to scale is to either teach your application developers to really really understand relational databases and performance trade offs or don't allow them to be responsible for the data model.

In my experience I have seen more atrocities committed due to developers using a relational database as a file-system, an XML document, a key value store or some variation in between.

When people complain about scaling in relational databases they usually mean that it is more rigid, and not easily adapted to changes. Which is valid and is why you cannot apply software development practices to database design. With database design you have to plan for the future and think out how your solution will grow as to not paint yourself into a corner. Further in relational design there is no such thing as premature optimization, if one thinks there is, one has already failed at setting up a robust relational database architecture.

At one of my start-ups we supported massive amounts of traffic from Hotels.com, Orbitz, Travelocity and Expedia all looking for pricing and allotment each time someone hit their front door and we did it all on applications that where backed by relational databases. We never saw Google or Facebook size traffic, but we had constant load of more than any one of those travel sites and many times load of all of them combined.

A solid application architecture and a sound relational model can scale quite well you just have to have good people that understand each discipline.

</comment><comment><USER9> It's useful to differentiate between "SQL Databases do not scale" and "SQL Databases do not _cost effectively_ scale". The second argument is more accurate.

Vertical scaling of a DB is definitely an option for many people and has been used to scale many applications. However, the cost curve associated with buying bigger and bigger hardware is super-linear; doubling CPU & Memory in a single system leads to more than doubling the hardware cost. This can be problematic for many businesses whose revenue growth is exceeded by cost growth of the database.

Sharding is also an option for scaling, leveraged to great success by Facebook, Yahoo, and many others. However as the article points out, sharding prevents the developer from using many of the features that make a relational database a productive development environment. There are lots of foot guns that emerge in a sharded SQL environment and if you have not set up your development constraints appropriately, you can slow the pace of development considerably. This again leads to a cost problem because the incremental costs of adding features grows as you add more things like sharding around your database.

SQL is not useless and not hopeless. In a large number of cases, SQL is the right solution. However the techniques used to scale SQL tend to be options only to very large budget organisations. NoSQL solutions tend to be more cost effective in their scaling approach (scale out vs. scale up) without crippling the developers productivity. For these reasons, NoSQL solutions tend to be the better choice for the cost-conscious.

</comment><comment><USER10> "SQL" is not a classification of a database, it's a query language. Some of the databases which use SQL do not scale well or easily, and some databases which don't use SQL don't scale well either.

What Adam means to say is "some of the semantics defined by SQL are hard to get correct while maintaining scalability." Hard is very different from impossible, and there is a large number of very smart people currently solving this problem very well. There is another large number of smart people trying to solve the problem by ignoring the hard parts of the semantics. It seems they will likely come up with something very fast and scalable, but ultimately less useful for certain things which are done easier with proper SQL semantics. In fact, it's not clear in all cases that they are even making something that's more performant: cf. [http://sergeitsar.blogspot.com/2011/01/mongodb-vs- clustrix-c...](http://sergeitsar.blogspot.com/2011/01/mongodb-vs-clustrix- comparison-part-1.html)

Saying "SQL Databases Don't Scale" is like saying "oil paintings on wood aren't appealing". Not all oil-on-wood paintings are good, but some are, and some tempera-on-fresco paintings suck too. The logic is simply invalid.

</comment><comment><USER11> >> When hundreds of companies and thousands of the brightest programmers and sysadmins have been trying to solve a problem for twenty years and still haven't managed to come up with an obvious solution that everyone adopts, that says to me the problem is unsolvable.

I take issue with the assumption here. What you want, which is obviously "free/open mysql-ish thing that scales indefinatly", is not a problem people have been working that hard to solve until quite recently.

To put it in perspective, 20 years ago, many banks offered no access to your money outside open hours and the internet was not a thing normal people used.

Today, if you go to Oracle or IBM, you'll find that they'll be happy to help you solve your enourmous problem at great profit to them. The thing that's changed in the last few years, is that Web 2.0 guys want the same power (or more) for a tiny fraction of the cost.

This is a good thing. This is exciting. People recognize that the status quo sucks and are working hard on change. The solution will probably involve some SQL, and probably some other tools as well. Don't be such a downer. ;-)

</comment><comment><USER12> Dupe <http://news.ycombinator.com/item?id=859468>

And here too <http://news.ycombinator.com/item?id=690656>

</comment><comment><USER13> MySpace uses SQL. If that isn't a vote for SQL scalability then I don't know what is.

<comment><USER14> What's MySpace?

</comment></comment><comment><USER15> Isn't that what Oracle RAC is for? If you are managing that much data, and you don't want to go the specialty DB route (nosql, for example) RAC scales.

It's also hellishly complicated, but so is the problem.

<comment><USER8> Right I feel like some times when someone say relational databases don't scale they mean that free databases don't scale without a lot of work. Scaling with Oracle is fast and easy (in comparison to the alternatives), it is why people still pay that kind of money for it. I personally find Oracle the company distasteful but the facts are the facts and Oracle does scale.

<comment><USER15> Sometimes I wonder... if three fortune 500 companies just spent the same amount as their Oracle budget on Postgres devs, they could probably have a RAC competitor in three years.

Then, just another billion on transition costs, right? :)

<comment><USER8> I agree, there is no technical reasons that postgres could not be as easy or as good at scaling as Oracle. Someone just has to put the money and effort in.

</comment></comment></comment></comment><comment><USER16> DB2 pureScale (<http://programmingzen.com/2009/10/21/what-is-db2-purescale/>). Checkmate.

</comment><comment><USER17> Sure SQL databases can scale. Oracle for instance has a parallel query option, but it costs real money and needs a lot of planning and configuration.

NoSQL databases scale much easier. Just add a new node and you are done. +1. Many of them are also freeware. +1 again. Many of them are also faster, because no parsing is done, +1. Many of them don't have and don't need locking. +1. No looks mean no write waiting. +1.

Decide yourself.

</comment><comment><USER18> Oracle RAC may come closest to addressing most of these issues. Of course it is pricey. However it fulfills pretty much all the constraints mentioned here - application transparency while scaling(sharding does not involve changing the app), horizontal scalability(add nodes as needed), failover for both read & write transactions. It sounds like sale-pitch for RAC but it seems to geared to deal with these kind of scenarios.

<comment><USER11> RAC uses a shared disk; it doesn't eliminate the single point of failure. The shared disk also adds a contention point, such that RAC often stops scaling after a handful of nodes. Even the first few don't give you linear scalability without changes to the application and extensive tuning.

I'm not trying to defend the article though.

</comment></comment><comment><USER19> (2009)

</comment><comment><USER20> This is baffling to me that the founder of Heroku, a service specifically on automated web scalability, would write an article on how SQL doesn't scale, when he uses Postgres as the de facto database for all of his customers.

</comment><comment><USER21> Is this why Google developed BigTable? Have other companies developed their own BigTable-like solutions?</comment>


Lake Michigan Is So Clear Its Shipwrecks Are Visible from the Air - <AUTHOR> http://www.smithsonianmag.com/smart-news/sunken-ships-lake-michigan-are-visible-ghostly-blue-180955108/?no-ist <comment><USER2> I was waiting for the part where they explain that the water is so clear because of invasive non-native mussels that have pretty much taken over. In other words the lake isn't clear because it's clean, it's clear because it's dead.

So when new EPA regulations kick in that allow ships to now dump their bilge and ballast liquids anywhere they like, expect to get more of this.

(Best link I can find for a quick search: [http://www.straightdope.com/columns/read/2672/what-is-the- ze...](http://www.straightdope.com/columns/read/2672/what-is-the-zebra-mussel- doing-to-lake-michigan))

<comment><USER3> You're talking about the zebra mussel. I'm good friends with a bunch of very dedicated folks who are employed to protect the lakes (the Great Lakes that is). The zebra mussel was a terrible invasive species but isn't nearly as terrible as some of the other new options-for example Asian carp. We've managed to claw back some funding for the Great Lakes in the most recent round of budget cuts but it's not nearly enough. Something that needs to be addressed is Chicago and it's complete refusal to sever its waterways from the Great Lakes-through Chicago we have a straight line to the Mississippi and from there to the gulf and god knows what coming in. Just one more example of Chicago ruining things in Michigan.

<comment><USER4> I spent some of my youth on a lake absolutely overrun with zebra mussels. You couldn't even see any sand, just shells. It sucked.

Nearly 15 years later, they're all gone. I don't know why. No one on the lake needs to use water shoes and the beaches are beautiful.

I understand that zebra mussels suck and are terrible for the great lakes, but do we understand the long term repurcussions?

<comment><USER5> I'm guessing the zebra mussels died as their food source became less common. I was a bio major, and there's a name for the population collapse that happens when a species gets access to a new food source, grows quickly, and then collapses, but I forgot what it is.

I'll have to look at my population dynamics book later to see if I can remember.

<comment><USER6> Overshoot and collapse, most likely.

<comment><USER7> Pardon me. I am clueless about Biology.

By collapse, you mean all dead & extinct in the lake? As in, there is 0% chance of them returning from the dead like the eggs that are laid which is start growing once there is new food source?

If the zebra mussel are all dead, would it be possible to transplant a family of fish from some other lake, so they can start a life in Lake Michigan and bring it back to life?

<comment><USER8> I caught about 20, ~8lbs. lake trout on Lake Michigan last summer. The lake is _not_ literally dead.

<comment><USER9> For the last 3 summers, my family and I have gone salmon fishing with a charter company [1] in Lake Michigan near Algoma, WI. Each year we've caught ~15-20 fish. From my limited experience I have to agree with you.

[1]: [http://kinnskatch.com/](http://kinnskatch.com/)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Michigander here: not really a comment on this article per say, but if you've never visited the lakes, you should come by (during summer) and check them out.

Some good spots on the Lake Michigan side (which I'm most familiar with):

Sleeping Bear Dunes: [http://www.sleepingbeardunes.com/](http://www.sleepingbeardunes.com/)

Saugatuck Dunes: [http://www.michigan.org/property/saugatuck-dunes-state- park](http://www.michigan.org/property/saugatuck-dunes-state-park)

Mackinac Bridge: [http://www.mackinacbridge.org/](http://www.mackinacbridge.org/)

(BTW, the last "c" in Mackinac" is silent)

Ludington State Park: [http://www.michigandnr.com/parksandtrails/Details.aspx?id=46...](http://www.michigandnr.com/parksandtrails/Details.aspx?id=468&type=SPRK)

Petoskey State Park: [http://www.michigandnr.com/parksandtrails/Details.aspx?type=...](http://www.michigandnr.com/parksandtrails/Details.aspx?type=SPRK&id=483)

Traverse City: [https://www.traversecity.com/](https://www.traversecity.com/)

Holland: [http://www.michigandnr.com/parksandtrails/Details.aspx?type=...](http://www.michigandnr.com/parksandtrails/Details.aspx?type=SPRK&id=458)

<comment><USER11> Tangential, but it's "per se"; the phrase comes from Latin.

<comment><USER12> And extra tangential, but "perse" is pejorative Finnish for "ass".

</comment></comment></comment><comment><USER13> Still interesting, but posted on April 27, 2015. Not exactly "right now".

<comment><USER14> Title needs a (2015), yes.

</comment></comment><comment><USER15> Great explanation of this: [http://nautil.us/issue/46/balance/the-cancer-of- the-great-la...](http://nautil.us/issue/46/balance/the-cancer-of-the-great- lakes)

</comment><comment><USER16> I was more amazed at how many ads they could fit on my screen.

<comment><USER17> Here's what needs to be blocked:

\- [x+1] (No idea who they are)

\- Doubleclick Ad Exchange Buyer

\- Google Publisher Tags

\- QuantCast

\- ShareThrough

\- Google Analytics

\- Scorecard Research Beacon

\- WebTrends

\- Google AJAX search API (Google killed that last year)

\- Google Tag Manager

\- Facebook Connect

\- Disqus

\- ZergNet

\- Po.St ("The Most Advanced Social Sharing Platform for Brands")

\- Ooyalya Player

\- pages03.net -> mkt932.com -> silverpop.com -> IBM Watson Campaign Automation (Skynet v0.1?)

<comment><USER18> Looked up x+1

[https://www.abine.com/blog/2012/x1/](https://www.abine.com/blog/2012/x1/)

 _[x+1] is a data-driven marketing tool that profiles consumers as they browse online, which in turn lets companies estimate the lifetime value of those potential customers. It also lets companies target people in most of the places they go online: their email inboxes, their chats, the websites they visit, and more._

<comment><USER19> I wonder when they will start naming their shit by what is hardest to Google.

<comment><USER20> Only when their customer base finds them exclusively by not-Google.

</comment></comment></comment></comment></comment><comment><USER21> That's neat, but the pictured shipwreck is only in 6 feet of water. Lake Superior often has visibility of 100 feet or deeper! I remember canoeing on the lake with my dad and seeing the bottom of the lake crystal-clear, 70 feet down. Surreal.

[https://www.google.com/search?q=lake+superior+water+visibili...](https://www.google.com/search?q=lake+superior+water+visibility&tbm=isch)

</comment><comment><USER22> I remember being able to see the bottom clearly in 30+ feet of water. Truly beautiful!

</comment><comment><USER23> Thats from 2015

</comment><comment><USER23> Thats from 2015.

</comment><comment><USER24> This is at least the second time this article has been posted on HN over the years ([https://hn.algolia.com/?query=%09Lake%20Michigan%20Is%20So%2...](https://hn.algolia.com/?query=%09Lake%20Michigan%20Is%20So%20Clear%20Right%20Now%20Its%20Shipwrecks%20Are%20Visible%20from%20the%20Air&sort=byPopularity&prefix&page=0&dateRange=all&type=story)). Makes it to the front page pretty much every time

<comment><USER25> > Makes it to the front page pretty much every time

All 2 times?</comment></comment>


Ask HN: What do you do while compiling? - <AUTHOR>

As a software engineer I regularly encounter occasional downtimes on the order of 1-3 minutes. My knee-jerk response is to pull up HN, but that usually turns into a 10 minute downtime (or worse). What do you do to prevent loss of focus during these times? <comment><USER2> Since I don't have such downtime due to waiting for compiles, I'm not entirely sure what advice to offer.

Except:

Maybe you should spend that time trying to fix your long compile/recompile times. Odds are you're re-compiling too much, or your binary is quite monolithic and includes items that could be put into separate DLLs/shared objects.

</comment><comment><USER3> I currently work on a large C# app, and even though we got the compile times down to sub 30 seconds, I suffer from the same issue.

Nowadays, I will usually work on a feature in isolation in a new project so I get a nice focused feedback loop. It doesn't stop the procrastination when I have longer compiles, but it reduces the frequency at least.

</comment><comment><USER4> I browse the internet shops for faster hardware.

I used to continue editing code, but this is a bad idea, since I've got the "save" reflex activating every 10 second, so the compiler breaks on incomplete newly saved code.

</comment><comment><USER5> Nowdays I mostly use languages that have no or very short compile times, e.g., Lisp, ruby. An embarrassing amount of my glue code is in bash.

</comment><comment><USER6> I would look away from any monitors or phones..

usually stretch and enjoy the view from my window.

</comment><comment><USER7> HN too. :)

Go stand up and walk around. Stretch. It's good for you.</comment>