Mozilla adopts plain-vanilla password sign-in for Firefox sync - <AUTHOR> http://news.hitb.org/content/mozilla-adopts-plain-vanilla-password-sign-firefox-sync

<comment><USER2> I see this as a reaction to the competition they're facing with Google Chrome.

With Google Chrome you log into your Google account. email + password and all is good. It's _simple_ , but fundamentally insecure. Google, NSA and whoever else they partner with can poke at all your data without restriction because it is based on a centralized authentication model.

Firefox always based its sync on a _secure_ model where no data was stored unencrypted at Mozilla's sync-servers. There was no traditional "account" which Mozilla had to validate. You could also chose to use your own sync server. Either way, they can not peek at your data.

You gave Firefox your email and a "password" and from that it generated some private keys used to encrypt the data sent to Mozilla. Private keys which you then had to distribute to other Firefox'es one way or another.

They attempted to ease the pain by having some "pair this device" wizards with 3 simple values you could copy from device A to device B, but in the end it still meant that the superior security came at a cost.

No non-technical people I know use Firefox's sync, but everyone I know who use Chrome also use its sync feature.

When comparing browser, some people literally list out "sync" as thing Chrome does and Firefox doesn't. That tells you a lot about how a simple and in your face implementation can drive adaptation. (I think Chrome's approach is too in-your-face, but that's another discussion.)

I honestly believe Firefox's original model is superior once you get past the initial warts, but I can see why they are making the changes they do.

<comment><USER3> This isn't really accurate.

The problem with Firefox's current/old sync model is recovery. I.e., users think they're getting their stuff (history, passwords, etc) backed up, but when they lose their device, their data is gone forever, because almost none of them will have bothered to write down the long random string that functioned as their sync key. Also, the pairing was relatively hard to use for "normal" users.

In the newer Firefox Accounts model, yes, Mozilla will use a username/password model for users. However, the password is never sent to Mozilla in the clear, and data is still encrypted with a password-derived key before being sent to Mozilla. However, users can still recover their data because they know (something that can be used to generate) the key used to encrypt their data.

See here for more details: [https://github.com/mozilla/fxa-auth- server/wiki/onepw-protoc...](https://github.com/mozilla/fxa-auth- server/wiki/onepw-protocol)

I do think Mozilla would have promoted Sync more if it didn't have the recovery/UX issues I mentioned, so in that sense it might be a response to Google's model, but Mozilla's model still has a very well thought-out privacy strategy.

For those who actually liked the previous random key model + pairing, I think they might reinstate that as an option within the newer protocol/implementation at some point.

<comment><USER4> I really hate that this new model requires trust, whereas the old one did not. Even if I trust Mozilla not to peek, I have to accept that all my data, including all my passwords, now become subpoenable.

I get that the old model is too complicated for most people, but I really like it and am able to handle it just fine. I don't want to trust the NSA, damnit.

<comment><USER5> This is incorrect. Both in the new scheme and the old, sensitive data is encrypted. In the old scheme, this key was randomly generated, while in the new, it is derived from a password. Either way, you do not need to trust Mozilla.

The main security concern (as far as I can tell, and I'm far from an expert) seems to be that the KDF used in the new protocol is not as strong as the one used in the current Sync protocol.

You should read the link posted in the post you replied to, especially the security analysis. It is quite readable and might allay some of your fears.

</comment></comment></comment></comment><comment><USER6> Will Mozilla be removing the secure sync option or having this one in parallel?

I don't use it myself, but it's definitely worrying to see a secure option being potentially removed in favour of plaintext storage on servers outside the user's control.

<comment><USER7> I don't think it's stored in plain text, the post was about standard login/password signing in instead of too-complex current mechanism.

<comment><USER6> If it's a username/password pair, either the data has to be stored in plaintext, or with a key escrowed using the user password, which are not as secure as a private key only known to the user.

<comment><USER8> No, you can use a different system: don't send the password to the server, instead create a private/public key pair from the password (deterministically) and send only the public key to the server.

When you want to authenticate, just have the client sign something with the private key. If you want to encrypt on the client, it can just do PGP-like encryption (encrypt data with random AES key, encrypt that key with public key, send all to the server).

<comment><USER6> Considering the average user's password choice tendencies, that's still weaker than a key from a proper source of entropy, then password reuse on top of that.

That plus IIRC, RSA isn't deterministic even with the same seed. Not sure about generators for elliptic curve though.

<comment><USER9> They're using key-stretching to mitigate the use of bad passphrases, though reuse will still be an issue.

[https://wiki.mozilla.org/Identity/AttachedServices/KeyServer...](https://wiki.mozilla.org/Identity/AttachedServices/KeyServerProtocol#Client- Side_Key_Stretching)

And RSA is deterministic.

</comment></comment></comment></comment></comment></comment><comment><USER10> Now all my bookmarks, history, passwords and the like will be stored on a centralized server?

The decentralization, especially in the wake of the NSA/GCHQ revelations, was one of its main advantages.

Sigh. I may well have to turn Firefox sync off then.

<comment><USER8> They were already stored in a centralized server. They were just encrypted, and they'll continue to be.

<comment><USER10> Ah, looks like you're correct. [https://wiki.mozilla.org/Labs/Weave/Developer/FAQ#How_do_use...](https://wiki.mozilla.org/Labs/Weave/Developer/FAQ#How_do_users_know_their_data_is_secure.3F)

I'm still a little unsure if this new system is less secure, however.

<comment><USER6> With a password, of course it is.

</comment></comment></comment></comment><comment><USER8> The actual announcement from Mozilla: [https://blog.mozilla.org/futurereleases/2014/02/01/test- the-...](https://blog.mozilla.org/futurereleases/2014/02/01/test-the-new- firefox-sync-on-nightly-release-channel/)

</comment><comment><USER11> Not Mozilla Persona? Why wouldn't it be suitable for this purpose?

<comment><USER12> They want to encrypt your data on the client-side, so that no data is visible to Mozilla. The password is used to carry out this encryption.

</comment></comment><comment><USER13> What is the 'Firefox Account' the new sync system uses and how does it differ from Persona? Will I need a 'Firefox Account' for other Mozilla services? What about Firefox OS? It seems bizarre to me to have this additional account system while promoting Persona as the system for other people to use. Is Persona abandoned?

Edit: the article mentions a Firefox Account is needed to use the Firefox Marketplace too. That's a webapp which I thought would have suited Persona.

<comment><USER14> Firefox Accounts is a centralized authentication system based on email addresses and passwords. Persona is a decentralized authentication system based on proof of email address ownership.

For Sync, Persona isn't the right tool for the job. Specifically, Sync needs a human-memorable source of entropy (password), and minimal external dependencies so that recovery meets user expectations. It's possible that Accounts will eventually use Persona for email verification, but the centralized password is unlikely to go away.

Marketplace is in a similar situation, and actually uses a centralized, friendly fork of Persona so that it can proactively force users to re- authenticate before purchases and allow people to use the site before they complete their email verification. Those features might make their way into Persona in the future, but for now it felt better to trim them from Persona and switch Marketplace over to Firefox Accounts.

</comment></comment><comment><USER15> Aah good riddance to the older approach. Its a major fail from UX perspective. The long sync key was ridiculous to type.

<comment><USER16> Have an attitude like this and you will never have security or privacy.

<comment><USER6> Those who would sacrifice privacy for convenience deserve neither.

<comment><USER17> So you're implying that 99% of humanity will have no privacy nor security?

<comment><USER18> That appears to be where we are headed.

</comment></comment></comment></comment></comment><comment><USER19> I wonder if they would update Firefox Sync on iOS. Since it is pretty much dead.</comment>


RoR vs. What else? - <AUTHOR>

We are building an app that would eventually use machine learning techniques to give recommendations to users. We did our MVP on PHP and then ditched it to build a new version on RoR. Now people say that, RoR does not scale well (mySQL slows down the experience) and not certainly a great tech for machine learning. I am not quiet technical. Should I just go with RoR (investments already made) or change tech. What's the pragmatic call? <comment><USER3> [edit - one additional point which is probably more important than the rest. if you've already done one rewrite and you're thinking of another, your problem is you probably don't know how to move the ball down the field in a business sense so you're picking up the only hammer you have - <USER2> choice, and repeatedly swinging it. Take a step back, ask yourself if the problem is fear of the unknown, and attack the true problem - how do you get users to USE your product. If truly the answer is "my users don't want me to use Rails", I'd be shocked.]

First, I'd say I don't think you have anything to worry about.

Second, don't go replacing MySQL because you're worried about scale. I have yet to find a database that really _easily_ scales better. You can trade a whole lot of development time to use something like Cassandra or Riak, (which are both great for particular applications). Then you spend a huge, huge amount of time building queries that were easy in Rails and you actually didn't solve any end-user facing problems. You just made it where only one of your developers actually can create queries and nobody can maintain the code.

Third, don't go replacing Rails because you're worried about scale. It's not the fastest thing but it's just not worth losing sleep over.

Just add the appropriate technology where you need it - I probably wouldn't build a recommendation engine in Ruby; perhaps that is the only piece that you build using something else.

Here's what we often do @ Inaka - web and admin in Rails, business "logic" and stuff that needs to scale (either because we have tons of socket connections or because we have a lot of data to crunch) in Erlang. (Insert Java or Python or whatever you need for the backend piece in place of Erlang.)

Then build an internal HTTP API that Rails can talk to. Abstract that in a model class. Have Rails call into it as needed. RecommendationEngine.recommend(...) returns JSON with the magical results for your Rails app to render appropriately.

Typically we give our Rails users an "api key" (that they don't know about) that is used to authenticate calls to the backend service, so we don't even have to share user authentication schemes between the systems. Then you can use devise or whatever you want for Rails but don't have to re-implement the same password hashing algorithms - authenticating those users is just a quick lookup in the user table.

Sometimes that service API may even be part of a publicly available HTTP API. For instance, imagine the backend piece exposes part of its API to mobile devices. Then, some of the methods may be authenticated and some are open to the world.

<comment><USER4> Seconding that.

PHP doesn't scale. Java doesn't scale. Python doesn't scale.

If you wait for something that "scales", you'll never ship anything.

Scaling isn't done automatically, it's something that's applied to a problem. If MySQL doesn't scale, and it has proven itself to be very capable in a wide variety of circumstances, then what does?

The more you read about scaling, the more you realize there's no magic bullet, no magically scalable language or platform or framework. It's all about careful investigation of the nature of the problems, the bottlenecks, and developing solutions to address those.

</comment></comment><comment><USER5> Your web stack and your machine learning stack don't have to be the same. <http://scikit-learn.org/> is Python and very popular for machine learning. Here is a in depth training video [http://pyvideo.org/video/972/tutorial- scikit-learn-machine-l...](http://pyvideo.org/video/972/tutorial-scikit-learn- machine-learning-python)

<comment><USER6> <http://orange.biolab.si/> is also good. It has a nice GUI.

</comment></comment><comment><USER7> Don't believe the people who say RoR doesn't scale. Normaly the framework isn't the bottleneck. The most critical part (imho) is your database design (ex.: using shards for user data, using solr (not the db) for searches), ...

</comment><comment><USER8> I don't see a problem in using PHP. Consider how you break down your infrastructure. Don't build monolithic code-bases which you cannot maintain. Make small compact services (SOA) which you know you can build out quickly. RoR is for people who want to spend a lot of time learning the framework. At this point, it's so large you will probably never even feel like you can encompass it's full size. Kinda like django. Don't ditch php because people say it doesn't scale. YouPorn.com thought it scaled quite well. They get a crap load of traffic to boot.

</comment><comment><AUTHOR> \</comment><comment> Much appreciate the insights. We are actually less worried about scale now (We just got users and some revenue and we are a long shot away from scale problems). We did not want to go too far down the path where we carry tech debt so much that we have to re-do. Your answers tell that its okay to go the way we are going and there are still ways to keep the recommendations (Machine Learning part) separate. \---

I shall get back here to post a link to our product in about a week when we launch. Would very much appreciate comments then!

</comment><comment><USER9> Use a different stack for machine learning, and switch over to postgres - I'm fairly sure it'll scale better than mySQL

<comment><USER4> MySQL is as capable as Postgres and can be tuned just as fast. The differences between these two are features, not performance.

<comment><USER9> Hm, didn't know that, thanks!

</comment></comment></comment><comment><USER10> Replace MySQL with Percona XtraDB, and leverage aggressive "permacaching" for a start. Then it's more about splitting up your infrastructure and having mechanisms for dealing with increased load on different parts of it (ie high db load = spin up more DB machines)

<comment><USER4> You have no idea what the problem is and you're already advocating a change of platform? This is not how you scale. This is how you hit up a client for thousands of hours of "consulting" fees.

This performance problem could be because of missing indexes, grossly inefficient queries, or a whole host of other elementary problems that can be fixed with a keystroke.

<comment><USER10> Not advocating a change of platform at all - Percona is a drop-in replacement for MySQL, and XtraDB is backwards compatible with InnoDB which gets much more performance out of multicore systems. Unless your server has one core, it's a no-brainer.

</comment></comment></comment><comment><USER11> Can't you use RoR with a different storage backend like MongoDB ? It's hard to say without additional precisions on the algorithms and persistent datastructures.

</comment><comment><USER12> The pragmatic call is, wait until you need to scale, if at all.

<comment><USER13> This. It's less about scaling a framework, than it is about scaling your particular application.

If you find that MySQL is a bottleneck in particular, Ruby (and by extension Rails) has a wide range of database adapters and database ORM's available. Active Record itself has numerous adapters, which mean changing databases within the supported set shouldn't be too difficult.

Alternatively, you could use a different ORM such as DataMapper or one specific to the database you desire. Rails now let's you choose which ORM you wish to use, although if you're just getting started it might prove an additional learning curve as most of the documentation uses Active Record.</comment></comment>


Statecharts: A Visual Formalism for Complex Systems (1987) [pdf] - <AUTHOR> http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf <comment><AUTHOR> Statecharts were originally developed for the design of in-flight software for fighter aircraft.

Also of interest is David Harel's account of the history and development of Statecharts.[0]

[0] Statecharts in the Making: A Personal Account [http://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.H...](http://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.History.pdf)</comment>


Pair Programming Considered Harmful? - <AUTHOR> http://techcrunch.com/2012/03/03/pair-programming-considered-harmful/ <comment><USER3> The company that I currently work at uses pair programming extensively - <USER2> 100% but strives for 3 hours per day. Although I understand its value, actually doing pair programming can be exhausting and tedious. I've also found myself working twice as hard/fast during non-pairing hours b/c I knew that pairing would sometimes be painfully slow. Lately, I've tried to work productively with my pairing partner in tandem, rather than sitting in front of a monitor together 3 hours a day.

I love the company that I work at, so I'm not likely to let pair programming dissuade me from staying there, but when if and when I do look for a new job (or start my own company), I would be very wary of a shop that uses pair programming extensively. I really love working in a team and directly with others on projects, but pair programming can be very tedious, particularly if there is a big gap in experience between the two people in the pair.

We also use code reviews for all code that goes to production. I find this to be extremely valuable. For more complex pieces of code, we do 'design proposals' that are circulated within our small team (4 developers) to get feedback and improve the design of our code.

<comment><USER4> Yes, it is my experience too that pair programming works best when you both are at roughly equal levels of experience and both really want to succeed with the task at hand.

Code reviews in groups often work really good despite different levels of experience though.

It is exhausting to do pair programming, but when it really does work the feeling of progress and mutual knowledge sharing is awesome. In these optimal cases me and my coworkers have worked in pairs for 5-6 hours per day. Pushing on for longer would not have gained anything, rather the opposite.

<comment><USER5> I work with a lot of interns these days, doing what's essentially pair programming with them and I don't feel their lack of expertise brings me down at all. Instead, I find having to explain everything I do to them brings a clarity to my own mind that is difficult to obtain otherwise.

Of course it does help that when my explanations truly fail, I still have the nuclear option (Hey, they pay me to teach you this stuff, so just believe me) available, but (I'd like to think) I only rarely use it.

</comment></comment></comment><comment><USER6> I actually think pair programming cons/benefits is part of a larger pattern that I call "management overhead". The premise is any practice implemented to increase general quality risk being offset by decreased productivity of the top performers.

If you have skilled developers they will work more efficiently the less "management overhead" that is put upon them (processes, checklists, methodologies etc). They will simply self-regulate and a large amount of output of high quality. As the skill/experience of the developers in an organization drops management typically implements practices to better ensure quality. While providing checks and balances for the lowest denominator these will also typically slow down the best.

This is especially nefarious when you consider that a "great" programmer can be 10x (or more) as efficient as an average one. That's probably because they developed habits that make them so, and now you risk meddling with those habits. Making a 10x as efficient programmer 20% less productive can be costly.

The most insidious thing about this as top performers typically can stomach only so much "crap" that slow them down before leaving for another job. Which leaves the organisation with even less skilled workers that need even more "overhead" to control which in turn results in even more "good" employees leaving. Iterate a couple of years and you have an organization where it is very hard to do anything wrong but also almost impossible to get anything done because of all the committee's, best practices, etc

Of course pair programming is going to slow the best programmers down without adding much benefit. On the other hand for bad to average programmers pair programming will probably result in better code with will offset the reduced efficiency. From an organizational standpoint pair programming will reduce dependency on any one programmer.

It's up to every company to decide which trade-offs they're willing to make and balance that against the kind of employee's they have. Some lightweight practices might actually be beneficial even for the top performers but they do take some serious consideration to get right.

If you can manage it, hire really good developers and get out of their way.

<comment><USER7> your entire point is based on that 10x productivity rule. it keeps popping up. Is it just someone's gut feeling turned into an urban myth or have real studies been done?

<comment><USER8> The 10x comes from the fact that you have 10 fingers. The real number is going to depend wildly upon the context. I've been on projects in which some members contributed zero--and so the ratio is NaNx. On the other hand, if you're writing COBOL crud, the fastest typist will typically be the most productive.

<comment><USER9> I've been on projects (and I'm sure I'm not alone in this) in which some members contributed negative value.

To contribute zero a bad programmer would have to just sit around and reddit all day or whatever. Once the bad programmer starts writing code he is almost surely a net negative since eventually someone is going to have to rewrite his code and unless the code is completely decoupled from everything else, the time required to do that rewrite will exceed the time it would have taken if the bad programmer had never written any code at all.

</comment></comment></comment></comment><comment><USER10> Off topic, but the "considered harmful" titling meme annoys me. Dijkstra gets a pass, but it's now become a passive, cliched, content-free, overused way to say you disagree with something.

<comment><USER11> logging in to upvote parent. to me, tc has lost its journalistic credibility a while ago.

<comment><USER12> >tc has lost its journalistic credibility a while ago.

Around the time it was founded, I'd say

</comment></comment></comment><comment><USER13> I really dislike paired programming, and if I ever end up in another situation where all or most of the day is spent sharing the keyboard with another developer, I think I'd go insane. My first experience with it [1] was pretty bad from both a happiness and productivity perspective.

I've always thought that for the purpose of improving code quality and transferring knowledge, a formal code review process is much, much better. Indeed, I've always wished more development shops would utilize a code review process of some sort.

1\. [http://www.spenceruresk.com/2009/03/impaired-programming- how...](http://www.spenceruresk.com/2009/03/impaired-programming-how-neither- of-us-is-as-dumb-as-both-of-us/)

<comment><USER14> I find pair programming is useful for overcoming a _specific_ problem, after which you have to disband and each go off on your own. Examples:

\- The problem can be that programmer A is stuck on a piece of code or debugging: this is usually part of a bigger task which A has as the top thing in their mind, but for some reason can't make progress. Programmer B brings a fresh pair of eyes to the table, but looking at it alone makes no sense, because their mental model will be up and running much faster with A's help.

\- Onboarding. Programmer B is new to the project and programmer A gives an increasingly hands-on crash course of the project workflow and B's first task.

\- The high-level parts of major refactorings. Neither A nor B will have the whole existing structure of the code completely in their heads, but between them they have a more complete picture and stand a much better chance of not messing it up.

None of these should take more than a few hours, or maybe a day max, or you probably will go insane, yes. It probably also depends on personality, but you should hopefully not have any homicidal tendencies after just a few hours.

<comment><USER13> Sorry, I should have worded that a little more carefully. Yes, I agree there are situations where a limited-duration pairing is useful and even ideal.

It is only when pairing consumes most of your day for days or weeks on end that it gets really tiring and counter-productive.

<comment><USER14> FWIW, I agree with you about code reviews. I'd add that I've found in-person code reviews to be the most helpful from a communication point of view. For remote teams I suspect live screen sharing with audio is a reasonable substitute. I guess the downside compared to a formal annotated code review is that the latter is a kind of documentation. Not that I've ever referred back to one, but it's conceivable.

</comment></comment></comment></comment><comment><USER15> I have always found the idea of pair programming odd, because to wit, I don't know any other intellectually involved/creative endeavor that forces people to work in pairs like this. Even more fascinating is the absolute lack of data to show that pair programming does indeed improve group productivity (unless I missed it, please send me links if I have)

On a personal level, I absolutely detest the very idea of _fulltime_ pair programming, but I assume that its because of my personality. I hate it so much that when I was interviewing for gigs, the first thing I would ask is if they pair programmed, if they did, I'd politely remove myself from the running for that position with the company.

I have my moods, sometimes I want to work for 18hrs straight, sometimes, not so much. Sometimes I want to go down a rabbit hole that I know is stupid, I just want to because its exciting to try out possibilities. I hate that pair programming would seem to preclude all that (again I might be wrong).

I don't want to constantly be explaining why I'm doing something, it just seems tiring. It takes something I enjoy and turns it into 'work', where I'm just coding with someone, day in day out 8 hours a day. Good for the company I suppose.

I'm sure people love it though, what would be an interesting statistic to see is how many devs would pair program if they didn't have to.

<comment><USER16> _I don't want to constantly be explaining why I'm doing something, it just seems tiring._

This is my biggest objection to pairing. Usually when I'm first working on something new I don't really understand the problem so I'll slap together a very quick & dirty solution and then either refine it from there or toss it and start over. Being forced to slow down and verbalize my thought process at this stage just slows the process way down and makes me less willing to experiment.

Good code reviews seem to me to provide most of the upside of pair programming with none of the downside.

<comment><USER17> >Good code reviews seem to me to provide most of the upside of pair programming with none of the downside.

Your suspicions are accurate. I can't find it right now, but I remember reading a thorough study on software and the bugs eliminated by various processes. It was code reviews (multiple variations of them, in fact) that stood head and shoulders above the rest in preventing bugs from reaching production.

</comment></comment></comment><comment><USER18> Looking at a specific problem for a short period of time (10 minutes) with another competent programmer is one thing. But trying to concentrate with another person looking over your shoulder is aggravating. My experience is that you are more likely to take shortcuts to get the task over with. You don't want to do anything that is going to take real concentration because concentration is impossible when another person is likely to interrupt your thinking to converse. That is by far the worst part of pair programming.

Knowing that your mind is free to explore a problem to whatever depth is necessary is _absolutely critical_ to solving something non-trivial.

I find it really hard to explain the damage of interruption to non- programmers. Whether it is a girlfriend or a client that likes to talk while you're fixing their bugs. I don't think it is necessarily unique to our profession, but it is certainly rare enough that most people seem not to get it.

</comment><comment><USER14> The headline doesn't really reflect the article, though after all its waffling before getting to the point I don't think any of its conclusions are all that revolutionary. It comes down to this: when developing software in a team[1], you have conflicting requirements. Your programmers/designers need to communicate effectively enough with each other[2] to keep them pulling in the same direction, but you want to optimise individual productivity. The optimal balance will depend on the project, team size and of course the individuals involved. It will even fluctuate wildly throughout the project. So really, the best thing you can aim for is to create an environment that's flexible enough to adjust to a balance that is close enough to the optimum of the day.

I'm disappointed anyone _still_ believes any of these Methodologies with a capital M will fix their project. All the techniques mentioned should be part of the toolbox, but it's up to common sense to use them appropriately. _There is no substitute for common sense._

Still, I was pleasantly surprised after my considerable initial trepidation about reading a _programming_ article on TechCrunch.

[1] or probably doing anything else creative, but I can't speak from experience

[2] and, let's not forget, communicate with the actual users of the software

</comment><comment><USER19> This is definitely YMMV territory. On the whole, I think a formal pair programming process is probably a bad idea. I wouldn't want to work somewhere where I had to play that game. Perhaps, that just means I would be a poor choice for such a company. :) However, I wonder how many of the "great" who's-who of programmers would have actually liked such a process; sure, you can find some examples, probably, but I doubt many. It's probably a personality thing. If two people are so in sync that they can code without slowing each other down or getting in the way of each other thinking through complex ideas then they probably should be pair programming, but I just wonder how much of that really exists.

I think many of us program at our best with a little solitude. Now, I do think "pair programming" can be beneficial with solving a particular problem but this is like something everyone should know just from life.

</comment><comment><USER20> This article begins with the premise that Atul Gawande's insights may apply to programmers. However, Gawande's writing has dealt mostly with the work of people like surgeons (he's one) and airline pilots. There's a crucial difference between this kind of work and the work programmers do: surgeons and pilots have to get everything right in real time -- a very brief lapse in attention could lead to disastrous consequences. Programming is different: you can review code after it's been written and get the benefits of a second pair of eyes (or several extra pairs of eyes) examining it at leisure. So if pair programming makes a particular programmer more productive, that's fine, but if it makes other programmers less productive, no tragedy will result if they use code reviews instead.

That said, one of the major techniques that Gawande advocates is the use of checklists, which can be useful even to programmers working alone to make sure they haven't missed some important step (e.g., verifying that their code works against a live server, vs. just passing unit tests). His article in the New Yorker on checklists is interesting in its own right:

[http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_...](http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_gawande?currentPage=all)

</comment><comment><USER21> One thing which the article didn't highlight, which I discovered when our team tried to switch to a 100% pair environment - the variable skill and speed of individuals.

One of the biggest problems we had was developers getting frustrated inside their pairs, because one of the members of the pair was weaker in some way, either slower, less experienced at the product, or less skilled generally.

Not only this but in a diverse environment with multiple cultures, where various disciplines vary, it managed to increase stress levels a lot also (as an anecdotal example, one of our colleagues was wound tightly and liked to be very procedural, while the rest of us were very laid back). These people all worked great on their own -- and got along -- but as soon as you pair them it all goes to shit.

</comment><comment><USER22> The only account of pair programming that made me spend time considering it was the story of Guy Steele pairing with Richard Stallman. My overall takeaway is to treat pairing like mind melding, and if you can't get your minds to meld it's going to be disastrous. From <http://oreilly.com/openbook/freedom/ch06.html> :

"We sat down one morning," recalls Steele. "I was at the keyboard, and he was at my elbow," says Steele. "He was perfectly willing to let me type, but he was also telling me what to type.

The programming session lasted 10 hours. Throughout that entire time, Steele says, neither he nor Stallman took a break or made any small talk. By the end of the session, they had managed to hack the pretty print source code to just under 100 lines. "My fingers were on the keyboard the whole time," Steele recalls, "but it felt like both of our ideas were flowing onto the screen. He told me what to type, and I typed it."

The length of the session revealed itself when Steele finally left the AI Lab. Standing outside the building at 545 Tech Square, he was surprised to find himself surrounded by nighttime darkness. As a programmer, Steele was used to marathon coding sessions. Still, something about this session was different. Working with Stallman had forced Steele to block out all external stimuli and focus his entire mental energies on the task at hand. Looking back, Steele says he found the Stallman mind-meld both exhilarating and scary at the same time. "My first thought afterward was: it was a great experience, very intense, and that I never wanted to do it again in my life."

</comment><comment><USER23> This [redacted] pisses me off, I'm sorry. Jon writes well, but I read the New Yorker article on "Group Think" which he references... in TechCrunch. I'm as shocked as you are. It's speaks well of individual creative process and how brainstorming and really other processes are bull crap. Technically speaking. If you think back, before Agile and other methodologies came along, developers were doing more with less than I'd consider any of us are doing now. For the most part. Pairing works, no doubt but I _hate_ how institutionalized it's become. I'd work at Pivotal if I could, but they pair 100% of the time. I consider myself an introvert, for the most part too. Pairing is painful if it's not organic. The article is inconsiderate article because it's speaks nothing to the fact that our profession was built on the backs of people who are socially awkward and enjoy privacy if not a certain level of autonomy.

</comment><comment><USER24> I pair 100 percent of the day so 8 hours a day for the last year. It has been a very rewarding process. As a natural introvert pairing has made me a much more communicative person and my programming ability has significantly leveled up as well.

We pair with 2 monitors, 2 keyboards, and 2 mice facing each other with our own desks which I feel gives each person in the pair enough privacy and space to make us both very comfortable.

Is pairing intense? Yep. Is it worth it? Absolutely in my mind. The high quality of the code and the productivity is well worth it.

<comment><USER14> Do the screens display the same content, and do the input devices control the same cursor? I find this 2-desk pair programming a curious arrangement.

<comment><USER24> Exactly, one monitor is an iMac the other is a thunderbolt display. The display just mirrors the iMac. We each have our own keyboard and mouse which controls a single cursor. The monitors face opposite each other so we are sitting (almost) directly face to face so talking to each other is natural with minimal turning, which would occur if you sat next to each other.

<comment><USER14> Interesting. I have a feeling this would drive me insane in the long run. Is there a particular problem you're attacking with this arrangement? Did you try a different approach before that didn't work so well?

</comment></comment></comment></comment><comment><USER25> I think the conclusion he has is right. It's not appropriate to pair 100% of the time. Having said that if you look at the way Pivotal labs pair up, they have really strict rules about what's allowed on the 'floor' e.g. No laptops, no cellphones, no distractions. So while working alone can give you more privacy and space to become creative, unless you're really disciplined by yourself, pairing up can actually be beneficial in forcing you to become more productive.

I think the other thing the author fails to mention is that in terms of up- skilling developers, the process of pairing is quite useful. Often the pairing will naturally raise the level of the weaker programmer by virtue of being exposed to new ideas and solutions by the more experienced developer.

</comment><comment><USER26> _two coders at one keyboard..._

Pair programming without dual keyboards and mice deserves castigation.

<comment><USER27> Is there any good way to have two keyboards, two mice, both act semi independently? That is, I want two mouse pointers, and if mouse A clicks on a window, I want keyboard A bound to that same window; same with mouse B and keyboard B (and of course they can also each click on and be bound to the same window as needed). Preferably a Linux solution, but something on Windows would be OK also.

What often happens, is someone would ask me to help them look at something, but they are multitasking multiple problems. Initially I can take over their keyboard & screen, but before long another call comes up and I have to transfer the problem / environment back to my desk, and get back to them (or end up owning the problem completely).

I think having the keyboard & pointer independence combined with an editor that lets you have multiple windows attached to the same edit buffer (like Emacs) would be wonderful.

<comment><USER23> You could try mirroring monitors.

<comment><USER27> But in that case, both monitors are still tied to the same workspace, and only one window can be active at a time. I'm looking for a way to have two active windows, each with its own keyboard attached.

<comment><USER23> This might be worth a read. Tom Dale wrote about his setup. There's a reference to how Pivotal Labs is setup too. I prefer the later if you can afford it.

<http://tomdale.net/2012/01/tildes-pairing-setup/></comment></comment></comment></comment></comment>


New discoveries set to reveal the geology of planets outside our solar system - <AUTHOR> https://phys.org/news/2019-12-discoveries-reveal-geology-planets-solar.html <comment><USER2> A new Golden Age in Astronomy is indeed upon us. And it looks like there is now re-newed focus on the search for extra terrestrial life.

[https://science.nrao.edu/science/meetings/2020/aaas](https://science.nrao.edu/science/meetings/2020/aaas)

A good way to get involved may be through NASA's AI/ML accelerator: Frontier Development Lab

[https://frontierdevelopmentlab.org/](https://frontierdevelopmentlab.org/)

<comment><USER3> Or it is the death of astronomy. At the moment _astro_ nomy melds together the study of stars and planets. That made sense when we had only a handful of interesting planets (plus many thousands of supposedly inert rock things). Now we know that asteroids are dynamic interesting objects. Pluto is not an inert ball of ice but an interesting planet as complex as any other. And then we have the steady flow of new exoplanets. Astronomy will soon split into formal astro-nomy, the study of stars, and planet-ology, the study of planets.

Today's astronomers are physicists. The study of stars takes data and theory from the high-minded world of particle physics. Fusion in accelerators on earth is used to study and define fusion that powers stars. Planetology will take data and theory from what Sheldon called "the dirt people". The science of rocks, soil and weather will lead the study of planets. This cultural split will soon divide astronomy. With all the interesting new stuff happening in relation to planets and the inevitable discovery/debate re life on those planets, the old guard of star-studying astronomers will be sidelined.

<comment><USER4> > The science of rocks, soil and weather will lead the study of planets.

Sounds great to me :)

</comment></comment></comment><comment><USER5> read it as "plants" and thought "well, that headline escalated quickly!"</comment>


Intermittent Fasting Methods: Which One Is Best for You? - <AUTHOR> https://dailyburn.com/life/health/intermittent-fasting-methods/ <comment><USER2> I use the sixth method, which is to trick my body into thinking I am under stress which is the same thing intermittent fasting does (Hormesis). I start with cold water in the shower in the morning. I also use a combination of broccoli and resveratrol to increase NAD production, every other day. Broccoli also contains Sulforaphane which is a natural pesticide, that also trigger hormesis in humans. This has the added benefit of increasing the excretion of benzene.

In terms of daily diet, I restrict my caloric intake in the evening, but that technically is not intermittent fasting. This is because I keep a coating of diet cranberry juice in my gut to promote healing after some dumb things I did a couple of years ago. I use K2 MK4 and MK7 to absorb calcium before the oxylate from the cranberry juice gets to it, otherwise I would have a greater risk of kidney stones.</comment>


Attracting great engineers - <AUTHOR> http://tomblomfield.com/post/61958629156/startup-series-part-2-attracting-great-engineers

<comment><USER3> > we strongly encourage people to choose between the MacBook Pro and Air. > We've had several people originally opt for various flavours of Linux, but > they've all swapped over to Macs within 12 months.

I'm curious if they've swapped more because of their own personal preference, or the "strong encouragement" from your team, or some combination of both. While I completely get the added value that comes from the homogeneity of equipment in the office, as a Linux guy, I've interviewed in places where they were basically like "Yeah, we're a mac shop, and you need to be too". It was kind of a turn off. I like macs and don't mind using them, but at the end of the day I'm a big believer in going back to the tools you're most comfortable with.

I guess what I'm trying to ask here is, how do you strongly encourage people to go for MB Pro or MB Air, without coming off as overly pushy? Interested to hear how you strike that balance, because I agree 100% that getting most of the team on the same equipment (or roughly so) is a big plus.

<comment><USER4> I generally ask people to all use the same tools so that they can interract on each other's machine, and so that the code is all looking the same (unless someone is trying a new tool, of course). Development is about collaboration and thinking, it's not about typing fast or other time sensitive things. But i explain all this at the interview, so that candidates can determine themselve before accepting a job. Switching to linux would emcompass convincing the whole team.

<comment><USER5> On the other hand, I see a developer's tools as an extension of his or her mind. Enforcing that everyone uses the same tools seems like a great way to encourage hive mind thinking.

Especially proprietary tools that can not be automated or extended is something you should be wary of pushing onto for example a bash and vim wielding programmer, unless your business has no need for major productivity gains to grow or to sustain itself.

<comment><USER4> I don't encourage hive mind, by other means. The proprietary tools I recently used where automatable with either apple script system or in java for jetbrain product, but generaly we would do a lot of command line automation because we are more proficient in that. And I try to push products designed for their users instead of designed for their licence or their developers to my product team. But also i leave the freedom to my team to change the tools, every wednesday, we can change some tools, for the whole team.

</comment></comment></comment></comment><comment><USER6> Unchecked assumption: the developers most likely to engage with "incendiary" posts about "ditching Responsive Design", or developers that show up at developer conferences, are most likely to be the "top engineers". Why do we think that? How do we validate whether that's true?

<comment><USER7> On the one hand, I agree that the idea of needing to engage with blogs and conferences in order to succeed as an engineer is way oversold. The whole point of engineering, after all, is to create artifacts that speak for themselves.

On the other hand, I think I might know "why we think that": If hiring is the hardest and most important problem facing most companies, which people keep telling me it is, then it pays to hire with an eye toward further hiring. You might therefore put a premium on hiring people who engage with others via writing and conferences, not because these are necessarily the best widget designers, sprocket debuggers, or gadget platers, but because you expect these people are more likely to go out into the world and be _noticed_ by the great designers, debuggers and platers who you'll want to hire next.

Obviously this can be overdone, and if you feed this process back on itself you'll end up with a one-dimensional clique of a company - in part because blog posts and developer conferences are a very narrow and biased sample of the universe of competent and potentially-competent people. But it shouldn't be surprising that companies _think_ that "always be advertising" is a characteristic of a "top engineer": The problems of hiring are at the top of management's mind, and are probably the _only_ thing at the top of _upper_ management's mind - in my experience, the CEO could not care less about the glitches in the firewall-configuration system, but she interviews half a dozen candidates every day. Every all-hands meeting is filled with exhortations to blog more, shake more hands, hand out more cards, meet more people.

</comment></comment><comment><USER8> I've been wondering recently whether having a team of top flight developers in your tiny startup is actually a good idea. Developers need things to do. More developers directly equates to adding features (assuming you have a reasonable team who understand modern deployment, frameworks, testing, etc). It must be possible to have more development resources than you can do user testing for (eg finding out what users want/need).

At what point does available development talent make "featuritis" inevitable?

Clearly, in a startup like GoCardless where they're dealing with banks, financial regulations, etc that's unlikely to be a problem, but if you're making yet-another-photo-sharing-app or it's-just-chat-but-different-this- time-honest-dot-io it should be a small concern.

</comment><comment><USER9> "...based on a £40k salary..." How sad that it's still considered "normal" in London. So basically toys and noise are cheaper than hard cash. No wonder best devs go to finance.

<comment><USER10> Well, it seems thinking behind salaries at startups in London is simple - <USER2> a cheap workforce (ideally fresh uni graduates) and let them falsely believe that they can get rich by giving them a tiny slice of stock options. Ironically the people who are hiring them would very often badly struggle passing tech interview at another company - especially when sometimes you're interviewed by people who have no background in CS.

</comment></comment><comment><USER4> I'm always a little bit warry of "developper marketing" like blog and conferences, because when you do that you're not developping, and this shows skills that are quite different than the ones required for software development. Marketing is all about mass media one way communication (broadcast), development is at most two way personal communication.

<comment><AUTHOR> I think blogging is actually much more a 2-way communication than traditional broadcast media. See this discussion as an example.

If you sit in your office writing fantastic software without telling anyone about it, you're destined for a pretty lonely future.

<comment><USER4> Participation on the internet is around 1%(edits on wikipedia), that's way more than tradionnal media, and 1% of a one to one conversation. Blogging is still putting on a suit, climbing on a soapbox, reading an edited speech and answering publicly to remarks (ie taking stances, playing roles).

</comment></comment></comment><comment><USER11> they already have jobs so you have to poach them from where they're working; netflix/facebook/google etc. you do that with money. all this other stuff should be taken for granted. if you're hiring engineers that are failing google interviews then you're not hiring the great ones now are you.

the problem is that most companies don't have the ability to poach great engineers, but they pretend they do so they go and write little posts like this one, but ironically they aren't qualified to be writing these posts in the first place!

<comment><USER12> People leave big companies for smaller companies for a variety of reasons that don't have to do with money: product, culture, team, technology, or just for the sake of working at a smaller company. And for the record, Google is not a perfect Utopia that has a monopoly on all the good developers with a flawless interviewing system.</comment></comment>


Hyperloop: Why can't we believe in the big ideas? - <AUTHOR> http://news.cnet.com/8301-31322_3-57598213-256/hyperloop-why-cant-we-believe-in-the-big-ideas/ <comment><USER2> I'm still not quite convinced that enough people care about getting from LA > SF and back again. The Hyperloop would be infinitely more useful (and might actually get done) if it were from Boston to DC (with NYC and Philly stops in between).

[http://en.wikipedia.org/wiki/Northeast_megalopolis](http://en.wikipedia.org/wiki/Northeast_megalopolis)

<comment><USER3> > The Hyperloop would be infinitely more useful (and might actually get done) > if it were from Boston to DC (with NYC and Philly stops in between).

There's already a "high speed" rail system between those points. Of course, that depends on your definition of high speed.

[http://www.amtrak.com/acela-express-train](http://www.amtrak.com/acela- express-train)

Having been on that line, you're lucky when you're going 50 mph. Having a hyperloop on those points would be insane. You could live in Boston and work in NYC.

</comment></comment><comment><USER4> In most practical ways Hyperloop is a train. It has a fixed unchangeable route that can be blocked by a single carriage. Without a massive network this will only be of value to people who happen to want to travel that particular route. The world has a long history of new methods emerging and they often fail in the long run. In Britain we had a canal boom, then a rail boom, and most of those routes are now closed or obsolete.

It would be better to concentrate on increasing public transport in the road and air. Build a separate road network for freight and coaches. Make energy efficient airplanes that can fly short distances quietly and land on short runways. Build systems to automatically route parcels to make same day delivery possible. This would create a network that would be much more adaptable and complement what already exists.

Rail is like dial-up between a few key points that ignores existing networks that could be upgraded. Hyperloop is just a faster connection to a dysfunctional network.

<comment><USER5> Roads? Where we're going we don't need roads.

Multi-lane roads are fixed routes that can be blocked by a single lorry and frequently are. Without a massive network increase, roads are rapidly becoming of appalling value on many major routes. Everything fails in the long run, including the current road network and we need ways to build capacity with minimum land use, because land rights are often the major cost.

Also, the car hauling version integrates directly with the road network anyway so I don't know really what your network complaint is about.

Besides, all transport upgrades, including road or rail, are just a faster connection to a dysfunctional network. If we were happy that it was properly functional, we wouldn't be looking to upgrade it.

<comment><USER4> People break down all the time, but mostly they pull over and are overtaken by the other traffic. I agree that heavy vehicles are a big problem which is why I suggested creating special provision just for them. Congestion from cars is bad for business because it blocks freight. Congestion from lorry's is bad for everyone. Imagine the benefit of removing all intercity freight from the roads?

<comment><USER5> Is not just breakdowns that can hold up traffic, road vehicles also crash a lot more often than trains and congestion is harder to manage as you cannot regulate flow in the same way.

I am not anti-roads. Roads are great, they can link everywhere really easily, however they have issues that can be reduced by pairing them with high speed rail and air for long distance travel and light rail in urban centers for bike and foot passengers.

Never mind just freight, imagine removing intercity traffic from roads and being able to visit the next town along without having to compete for the road with the folk going 500 miles.

<comment><USER4> If all the vehicles are routed and controlled centrally with automated safety systems it could be more reliable than rail. I am not suggesting we build more roads as they are today, rather build a network that has the advantages of rail via automation and just happens to use new roads as a pathway.

</comment></comment></comment></comment></comment><comment><USER6> Hyperloop is a big step that would take at least 20 years to try. What San Francisco needs is simpler and smaller steps to fix transportation. Here are suggestions;

1- Allow private & small mini-busses.

2- Provide the community hanging out near the bart exits in Mission better public gathering places so we don't need to smell heavy amount of pie every morning.

3- Make screens in bart and stations that show the upcoming trains, current train, route etc.

4- Ban smoking, eating, talking loudly, and leaving garbage in the trains.

5- Replace all the seats with smaller ones like all other subways have.

6- Replace shitty Subway shops with good hipster alternatives that people actually enjoy.

7- Improve ferry transportation between east bay and san francisco.

8- Establish shuttles.

<comment><USER7> False dilemma and apples to oranges wrapped up in one comment. First, we can have people working on the hyperloop and also addressing these problems. Second, all of the things you mention have to do with intra-bay area transportation, and most of them have nothing to do with efficiency but with comfort, while the hyperloop is about efficient transport between two cities.

<comment><USER6> I already pointed hyperloop is the big step, these are small steps that we also should make.

As I observe, nobody responsible is giving a fuck to the problems of bart. A friend I met almost threw up in the 16th bart exit since it's used as public toilet. Aren't we paying half amount of the money we make to the government? Then why can't we push the city government to fix the bart?!

</comment></comment></comment><comment><USER8> I believe. Now all I need is $6billion to build this thing, and $10 billion to grease the palms of every politician between LA and San Francisco.

</comment><comment><USER9> Instead of LA to SF, I would look at building from Las Vegad to Arizona or to Riverside perhaps? As a first line to start with and it's through the desert.

Just a thought. Show the skeptics what is possible.

<comment><USER10> Good idea. However, there are lots more investors in the LA-SF region. This proposal is also a hack around government rules. This 'bid' is 9% the cost of the train bid, and there is already a government budget for it. The companies now have a track record of successul government bids (tesla paying back the loan, and spacex successfully sending rockets into space). SF,valley, LA types have been very supportive of tesla, and spacex - so I think they'll also be supportive of an innovative train replacement.

For these reasons I think this proposal is brilliant. It's a hack on government, business, media, and engineering all at once. As well, it's something the customers would prefer. Well played Musk.

<comment><USER11> _This 'bid' is 9% the cost of the train bid, and there is already a government budget for it._

I am not from California so I am not familiar with the HSR project. But this doesn't seem right to me. HSR is proven and Hyperloop is experimental. Why is it plausible that the same route for both would be cheaper on the one that is going to require more engineering and V&V?

<comment><USER12> This is discussed in detail in the hyperloop proposal, but I believe that the biggest factor is that the hyperloop proposal mostly runs along the I5 thus requiring much less expropriation and right of way development, and doesn't require large fences.

</comment></comment></comment></comment><comment><USER13> I think that this article does discredit how much smartphones have accomplished. Now anybody with a modern smartphone has a decent camera. Anybody has access to full Google search results in their pocket. It's possible that soon your smartphone will be your laptop (see Ubuntu Edge, and augmented reality setups that are being developed). Smartphones may one day be able to form their own meshnet using bluetooth.

Not to say that we shouldn't move forward with hyperloop, or at least build a proof-of-concept somewhere. At the proposed price for hyperloop, you could replace all existing Amtrak transportation in America with a hyperloop and still pay about the same amount for a ticket.

To me, that's worth investing in.

<comment><USER14> I enjoy having a search engine in my pocket (though I'd prefer if it weren't Google), and the ability to haul a stack of 600 and counting articles, and a few score books, while nary putting a crease in my chinos.

But we had books and encyclopedias and telegraphs and telephones and phonographs a century ago. Just ... not as distributed, or portable.

If you were to look at the inventions and advances of the last quarter of the 19th and first quart of the 20th centuries, I suspect you'd find a few more significant items than smartphones: electric light, telephones, phonographs, radio, television (just under the wire), indoor plumbing (made possible by central heating, so your pipes wouldn't freeze), air conditioning, and even the first practical computers. Oh, and airplanes.

If you had the choice of technology _since_ 1925 or _before_ , I think you'd go with the latter choice.

<comment><USER15> "But we had books and encyclopedias and telegraphs and telephones and phonographs a century ago. Just ... not as distributed, or portable."

Or as fast, or as comprehensive, or as cheap per unit of accessible data, or as connected, or as quick to improve and update, or as multi-functional, or as useful, and so on.

It's the difference between having "food" as a barbarian in 10,000 BC and having an integrated and highly advanced system of feeding an entire civilization of 300 million people. That is to say, the difference between night and day.

<comment><USER14> What had a bigger impact on the availability of information? The laptop / tablet and Google, or Gutenberg's press?

Prior to Gutenberg, if you wanted a copy of something, it had to be _copied out by hand_ (often with errors introduced). Copies of a great book might be numbered in the double digits. Newspapers didn't exist. Few people were literate, let alone possessed a library. By the 19th century you had penny dreadfuls, mass-market novels, and literacy rates in some countries approaching 100% (Sweden, Finland, and Estonia in particular -- England as late as 1843 had a literacy rate of 67% among men and around 55% for women).

The marginal benefit of additional technology, as with all marginal returns with stunningly few exceptions (Moore's law chief among them) is increasingly low, while the _costs_ of its discovery increases in real energy terms.

</comment></comment></comment></comment><comment><USER16> Hyperloop: $6 Billion

Budget of the NSA: $10 Billion ([http://money.cnn.com/2013/06/07/news/economy/nsa- surveillanc...](http://money.cnn.com/2013/06/07/news/economy/nsa-surveillance- cost/index.html))

Hopes and dreams of 1960s youth looking at Apollo and entering STEM fields: priceless

There are some things money still buys. For everything else there's PayPal??

<comment><USER17> Thou shalt not compare values of different units (USD vs USD/a)!

<comment><USER16> Technically you're correct, the best kind of correct.

But well, is there a pretty easily understood, common sense way to compare an yearly budget of $10B with a total cost of $6B, especially in terms of a trade off?

<comment><USER18> It just so happens there is! (Sort of.) A one time sum can be compared with recurring annual sums by calculating the present value of each, taking into account prevailing interest rates. The present value of an infinite series of annual payments is given by the perpetuity formula: PV = (annual payment) / (interest rate). Assuming that the NSA budget won't grow, and using the 30-year treasury bond rate of 3.71%, the present value (or cost, really) of having an NSA forever is $270B. Of course, the NSA's budget is probably growing faster than 3.71% right now which ruins the math, since it would imply an infinite NPV. Also, to be totally accurate you would have to calculate the present value of the hyperloop which would be spent over some number of years.

<comment><USER16> What might you do with your infinite series to roughly estimate the NPV in your head without having to write anything down?

Especially when faced with certain tradeoffs, like comparing a $6B hyperloop with an agency with an annual budget of $10B?

<comment> T-hawk Just divide the yearly cost by the rate of interest or inflation. $10 billion divided by 3.71% yields that $270 billion figure. Use whatever mental shortcuts work for arithmetic in other contexts. There's no need for an actual infinite series.

Explaining it the other way around, if you had $270 billion now, you could fund the NSA by $10 billion per year in perpetuity based on the interest. That's a simple calculation of $270B x 3.71%.

<comment><USER16> Must just be me. How about:

I'll trade 7 1/2 months of the NSA annual budget for one hyperloop.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> Simple really, government is to large and intrusive that there is little to no room for private industry to implement them. Items that are easily transportable, or measured at the personal level, like phones, computers, and even cars, are still well within reach.

Some will point to Space X as violating that last line, but look at it from the perspective of that it really is only affected by one part of government. Large transportation projects like the hyperloop would require approval at so many levels and be subject to the whims of so many outside groups that it is insurmountable by private enterprise. Only government can build it because only government can ignore its own rules.

So its not a matter of that we can't think big, we can think big all we want. We just have to find frontiers where bureaucracy is not the primary obstacle.

<comment><USER20> As well as Rand would like this story, with its normative, visionary captain of industry, its worth remembering that this line of thinking is as bankrupt as it is naive.

First of all, it would be utterly impossible for a purely private initiative to build the hyperloop as proposed. Most obviously, the unique feasibility argument here is that the government already owns highways that could bear the tube for most of the distance between SF and LA. But no serious rail line has ever or could ever be built without government help, because it would be impossible to negotiate the purchase of all the land without eminent domain.

Pragmatics aside, this is also just a very facile way of looking at things that belies, I think, a certain amount of laziness. The government isn't perfect, and sometimes bureaucracy does hinder good projects, but really the challenge for hyperloop would be garnering public support. If the proposal becomes massively popular, the government will have a huge incentive to build it. Unfortunately it's easier to complain vaguely about the government than it is to convince weary tax payers to fund a massive project using unproven technology. I'd love to see hyperloop built, but I am not desperate for other services that would be provided with the same money (better schools, for example).

Much of the reason American business thrived in the second half of the twentieth century is because of the superior infrastructure the government built. Every business in Y Combinator relies on services provided by the government and couldn't function nearly as well if Ron Paul were king. And, obviously, the government has achieved radically ambitious projects before. Have you ever been to Hoover Dam? Driven from coast to coast?

Government isnt perfect and can be frustrating, but bureaucracy is almost never the primary obstacle. It's just a convenient excuse.

<comment><USER21> The solution to negotiating land purchase without eminent domain is to play "connect 4" by buying "options" \- cheaper contracts that fix a price for a period of time but don't guarantee a sale. As soon as you have a connected path of options between A and B, you can exercise the options and run the line down it. You can spread the option purchases around a whole lot, so that nobody has an incentive to play awkward in return for more money, because you'd simply route around them.

</comment></comment></comment><comment><USER22> It's notable that Musk uses supersonic air travel as a comparison point. Talking about LA to NY: "...I believe the economics would probably favor a supersonic plane"

With reasonable timing: it's just coming up to a decade of supersonic air travel being commercially unviable.

<comment><USER15> I think it's his all-electric jet in the back of his mind.

[http://www.bloomberg.com/news/2013-08-08/elon-musk-just- may-...](http://www.bloomberg.com/news/2013-08-08/elon-musk-just-may-have-to- develop-an-electric-supersonic-jet.html)

</comment></comment><comment><USER23> If the expected value (estimated to the best of our abilities) is positive, then someone with a bit of credibility can easily create a corporation and find investors to build it. It's really that simple.

The only other way it might get built is if someone lobbies the state to fund the project, and in that case it's probably not worth it because the market didn't even want to do it. Isn't this what happened with California's new rail project?

<comment><USER24> It is not quite that simple. The government will have to say yes, since this is a big infrastructure project that wants land next to existing highways. I don't know much about politics, but I do know that, sadly, the net gain for the country over time is not a weighty criterion in such decisions.

<comment><USER23> Getting government support for the project is part of the risk and cost analysis, and I don't believe it would amount to a very large percentage of the total cost.

</comment></comment></comment><comment><USER25> I don't see how someone could put Google Glass in the same category as Segway or CableCard, especially this early on. I do wish CableCards had worked out better though. As it stands now, I have an HDHomerunPrime that I'm ready I part ways with because there simply isn't enough support for CableCards in Linux.

</comment><comment><USER26> She said it herself: it's another Segway. It's a solution in search of a problem. We already have mass transit between northern and southern California: airplanes. I know, I know, this would be "better". But the existing system serves the people who need it at an adequate cost and level of service.

<comment><USER7> This is a ridiculous comment. An hour door-to-door SF to LA means of transportation for less than $100 round trip would completely alter the economic landscape of California.

<comment><USER26> How? It's still too expensive for most people to use on a daily basis. It still requires some way to get from the train station to your final destination, which adds yet more cost. The end result is that the only people who will really use it are the same people who currently fly regularly between LA and SF, which means about 12 million people annually. Nowhere near enough ridership to support the kind of prices that are being bandied about.

Edit: more like 6 million people fly between LA and SF annually. I was thinking of the Amtrak Northeast Corridor ridership, which is about 12 million annually.

<comment><USER27> The paper outlines an amortization period that shows where that price comes from. Did you not read the paper?

<comment><USER26> Assuming the paper's optimistic predictions are feasible, the amortized cost per passenger of a one-way ticket is $20 plus operating costs. So, sure, the round trip cost will hopefully be somewhere below $100, if we ignore the cost of local transportation at either end. This is, as I said, too expensive for most people to afford on a daily basis.

Beyond that, the paper also claims a total annual ridership of 7.4 million people, so approximately the same ridership as currently served by air travel. So, other than acting as a jobs program, in what way will this alter the economic landscape of California?

<comment><USER28> A $20 ticket isn't enough that many people would commute on a daily basis (though many would), but a 40 minute trip is less than my commute to San Jose! You could come to SF to go to Napa or visit a concert, return south to LA for a movie premier or to hit the beaches, all as _day__trips_. How would this not have a huge impact for both cities?

</comment></comment></comment></comment></comment></comment><comment><USER29> I'm pretty sure there are plenty of places in Asia and Europe, where public transport is not a dirty word, where people are already trying to figure out a way to make this happen in their backyard.

<comment><USER30> I keep thinking about the Seattle Center Monorail, constructed for the 1962 World's Fair. Like the hyperloop, it's an elevated train, and people predicted that it would be extended to other cities and revolutionize public transportation.

It still runs, and you can ride it for a few dollars. But a bus will take you end-to-end cheaper and faster.

[https://en.wikipedia.org/wiki/Seattle_monorail](https://en.wikipedia.org/wiki/Seattle_monorail)

</comment></comment><comment><USER31> Just shows how unevenly wealth is distributed if one guy thinks about building a new transportation system between L.A. and S.F.

<comment><USER32> anyone can 'think' about building a transportation system. Even elon cannot pay for the new transport system by himself.

<comment><USER15> Musk could technically pay for it, his wealth is right around $6 to $7 billion (33m shares of Tesla worth $4.8b; $1b in SolarCity, and SpaceX is worth at least a billion to him, plausibly more), but it'd wipe him out.

There are reasonably a few individuals or groups of people in the world that can very safely spare the resources to build it (such that paying for it it wouldn't materially damage their business or ability to run their business, or otherwise tank their stock, put them in the poor house, and so on).

Bill Gates (Cascade can raise $10 billion quickly), Carlos Slim, Warren Buffett (the street already knows he's going to liquidate), the Koch brothers together could easily do it, Ellison could do it with leverage (he'd never sell that much Oracle stock in one go, and he earns enough annually in dividends to pay off the loan), and the Walton clan (but they'd be very unlikely to coordinate on such a thing).

For almost anybody else, the liquidity or leverage it would take would be overwhelming or very risky at the least.

<comment><USER33> You forgot Elon's lost twin, Sergey Brin.</comment></comment></comment></comment>


Please fix this, PG. - <AUTHOR> http://i.imgur.com/cuXza.jpg

<comment><USER2> At a guess I'd say that's what happens when you click 'more' on a page that's too old for 'more' to mean anything in that context.

<comment><USER3> I run into that quite a bit. It generally happens when you sit on a page for a long time - somewhere between half an hour and an hour, I'd guess.

How should this to be fixed (if it does)? 5 second timer on the 'Unknown/Expired Link' page that redirects to the front page?

<comment><USER4> If you can reasonably predict when the list will expire, removing the "more" link from the DOM (replacing it with a notification to go back to the first page) would remove some of the inconvenience. There are probably a few better ways to deal with it, I just don't understand why the problem needs to exist to begin with. The same problem exists on Reddit incidentally.

</comment></comment></comment><comment><USER5> pretty sure this is to slow/stop crawlers.

<comment><USER6> No, it's because the "More" links are implemented with closures, which then get garbage collected after a while.</comment></comment>


"There is no market" for VR that requires you to dedicate a room - <AUTHOR> http://vrsource.com/gtas-strauss-zelnick-no-market-vr-1593/ <comment><USER2> But lots of folks fixed up their family room/rumpus room for WII. I guess they may be in the minority.

<comment><USER3> The bulk of Wii games can be played from your couch.</comment></comment>


Ask HN: Am I under paid? - <AUTHOR> I make $150K base salary per year (besides stocks), with 10 years of experience total. I live in the san francisco bay area and feel like I'm underpaid. <comment><USER2> Damn man, if I could get a year of your salary, I'd be able to pay off my mortgage. I definitely don't make close to that, but then again, I live in a part of the country that is much cheaper. I'd say.. at least, I think you are doing pretty well. That sounds like a great salary, even though I know the cost of living there is insane. Almost better off getting yourself a trailer and living in it instead of having to pay the outrageous rent.

Check out this infographic I recently published on my website of Tech CEO salaries vs. their employee salaries and you will be able to get an idea of where you're at. Not a single employee at any tech company is making what you are making.

[http://www.confessionsoftheprofessions.com/ceo-vs- employee-s...](http://www.confessionsoftheprofessions.com/ceo-vs-employee- salary-interactive-infographic/)

</comment><comment><USER3> If you're the cofounder of a startup that just got accepted in to YC (reading your username) you are overpaid.

</comment><comment><USER4> I'm with ejcx. You got it made if you're a startup person making $150K in YC's program. You're doing better in terms of immediate benefit vs long-term possibilities than tons of other developers. I hope the startup works out for you but consider a tech hub with a lower cost of living if it doesn't. There's a lot of "tech cities" just a Google away with online tools for cost of living.

</comment><comment><USER5> I am in no position to judge your salary.

If you feel that you are being underpaid, then why go to HN about it? The best option would be to go directly to your management and negotiate a better salary. If they won't pay you what you ask for then you would go and find a job elsewhere that pays more than you are currently getting.

If neither approach yields you a higher salary, then the answer is that you are NOT underpaid.

</comment><comment><AUTHOR> FYI - I am not at a YC startup :)</comment>


The Mystery of Go, the Ancient Game That Computers Still Can't Win - <AUTHOR> http://www.wired.com/2014/05/the-world-of-computer-go

<comment><USER2> Previous discussion: [https://news.ycombinator.com/item?id=7732393](https://news.ycombinator.com/item?id=7732393)

<comment><USER3> This one is actually the third submission: [https://hn.algolia.com/?q=%22the- world-of-computer-go%22#!/s...](https://hn.algolia.com/?q=%22the-world-of- computer-go%22#!/story/forever/0/%22the-world-of-computer-go%22)

</comment></comment><comment><USER4> For a dissenting opinion, see my blog post from 2012: [http://blog.printf.net/articles/2012/02/23/computers-are- ver...](http://blog.printf.net/articles/2012/02/23/computers-are-very-good-at- the-game-of-go/)

<comment><USER5> Very interesting read, thanks for posting it! I'm not really familiar with that domain, could you tell me whether it's possible that the reason Go bots are not as strong as chess bots (in relation to humans) is simply because chess is a much more popular game that, and more time and effort has gone into making those AI stronger? Go is touted as having a much larger search space than chess, but that probably means that it's harder for humans as well, no?

<comment><USER4> You're welcome. Popularity might well be some of it, but I think that effect's worn off by now.

I think the main reason has to do with score estimation. With chess, you can say that a queen is worth 8 points and a rook is worth 5 and a bishop's worth 3, and get a quick idea of who's winning a game. In Go, every piece has the same value, and whether a stone is useful depends on which other stones it's connected to, and whether those stones are going to be alive at the end of the game. So just to work out whether you're winning, you have to be able to do search all the way to the end of the game and work out who wins! And computers have been getting that process wrong until recently.

The extra search space doesn't make Go harder for humans too, because humans play both Chess and Go very differently to computers. A human never tries to calculate the value of a million possible moves, so the question of how many million possible moves there are to search through just isn't relevant to a human. Humans play both Chess and Go largely using pattern recognition and insight in a way that computers are not currently able to model.

</comment></comment></comment><comment><USER6> What a rambling purple-prose article. Why can't it just cut to the point? Why should I care what the people were wearing? Why does that merit a paragraph of description?</comment>


Finally a node module to consume RESTful APIs/endpoints in an ORM fashion - <AUTHOR> https://github.com/ngonzalvez/rest-facade <comment><USER2> Nice, but IMHO not quite there.

Have a look at the design of [https://github.com/whichdigital/active-rest- client/blob/mast...](https://github.com/whichdigital/active-rest- client/blob/master/README.md)

It really covers all the bases while still leaving space for exceptional cases.</comment>


iPhone 6 all reviews aggregated - <AUTHOR> https://feedcheck.co/blog/iphone-6-customer-reviews/ <comment><AUTHOR> You can use this embedded code to show real time statistics about iPhone 6. This statistics are made from eCommerce reviews.</comment>


ZyLAB - <AUTHOR> https://www.zylab.com/ <comment><AUTHOR> ZyLAB ONE eDiscovery uses Artificial Intelligence and Data Science tools to facilitate fact-finding missions through large or small electronic datasets related to the business-critical projects of governmental agencies, law firms, and companies of any size.</comment>