First 26 pages of Neal Stephenson's new novel Seveneves - <AUTHOR> http://www.nealstephenson.com/news/2015/04/13/seveneves-excerpt/ <comment><USER2> It seems like my first knee-jerk impression of every Stephenson novel of the last decade has been "ugh, terrible", gradually replaced by a retrospective fondness after finishing it.

The first couple pages of Seveneves certainly does not impress, but maybe I'll like it better after reading the whole thing.

<comment><USER3> Anathem was kind of a slog for the first 200-250 pages, but then it started to get good, and then awesome, by the end of the book my mind was thoroughly blown.

<comment><USER4> I didn't find the beginning quite a slog but I did wonder if there was going to be a "plot" in the conventional sense. As you say, the rest of the book was a near-continuous crescendo. One scene in particular (Saunt Bucker's Basket!) made me literally stop reading while my brain processed.

My wife read my copy after me. If I remember correctly, she more or less read up to that scene in 5-10 page increments, and then read from that scene to the end in most of one night.

<comment><USER5> > _Saunt Bucker 's Basket!_

That was, bar none, the best reading experience in my life.

</comment></comment></comment></comment><comment><USER6> This helped make reading this a little easier. Copy and paste to your URL bar. You may have to retype the javascript: as it appears to get stripped for security.

      javascript:$('.entry').css({ "background":"#fff","color":"#333","padding":"10px","font-family":"Arial, 'Helvetica Neue', Helvetica, sans-serif","font-size":"14px","font-style":"normal","font-variant":"normal","font-weight":"400","line-height":"20px" })

<comment><USER7> You can also just turn styles off ("View > Page Style > No Style" in Firefox).

<comment><USER8> Or even better, if you`re in a recent version of Firefox you can click on the little "open book" icon in the address bar and enter the reader mode which looks pretty nice as can be seen in [http://i.imgur.com/oiZGekO.png](http://i.imgur.com/oiZGekO.png)

</comment></comment></comment><comment><USER2>
         "Most black holes are formed when stars collapse," Ivy said.
         "But there's a theory that some of them were created shortly
         after the Big Bang. The universe was lumpy. Some of the lumps
         might have been dense enough to undergo gravitational
         collapse. They could form black holes that instead of
         weighing what a star weighs could be a lot smaller."
         "How small?"
         "I don't think there's a lower limit."

Yes there is. Black holes lose mass by Hawking radiation: [http://en.wikipedia.org/wiki/Hawking_radiation](http://en.wikipedia.org/wiki/Hawking_radiation)

A black hole smaller than 0.8% Earth masses loses more mass than it gains from the cosmic microwave background, and will eventually evaporate.

<comment><USER9> That doesn't create a lower limit, just a life expectancy. And the life expectancy is still very long — "within the lifespan of the universe" [http://en.m.wikipedia.org/wiki/Micro_black_hole](http://en.m.wikipedia.org/wiki/Micro_black_hole)

<comment><USER2> You are mistaken.

[http://arxiv.org/abs/0908.1803v1](http://arxiv.org/abs/0908.1803v1) (See the table on page 15)

The lifespan of a 108,000 tonne black hole is ~350 hours. At that mass, its event horizon is .32 attometres across, and the Hawking radiation it emits is measured in gigaelectronvolts.

<comment><USER9> 350h is a lifespan, and you're quoting a speculative paper. I haven't read the story extract, but I assume the plan would be to bleed matter into the micro black hole to maintain it. (Arthur C Clarke posited the same concept 40 odd years ago in his Imperial Earth novels.)

I assume your point is that a GeV is a minuscule amount of energy, which isn't going to push 130kT around at any speed.

<comment><USER2>
      you're quoting a speculative paper.

Hawking radiation has never been directly observed, but it is generally presumed to exist.

      I haven't read the story extract, but I assume the plan
      would be to bleed matter into the micro black hole to
      maintain it.

Read the story. In context, the character is talking about how small a natural, primordial black hole can be. There is an obvious lower bound, due to Hawking radiation.

      I assume your point is that a GeV is a minuscule amount of
      energy, which isn't going to push 130kT around at any speed.

Read the paper. That's the pseudotemperature of the event horizon. It's so hot that it's glowing largely in ultraenergetic gamma rays. The total power radiated by a .32 attometre black hole is 5,519 petawatts.

</comment></comment></comment></comment></comment><comment><USER10> I love this on his page about the novel:

"The only part that gave me any trouble was calibrating an ending that would leave the reader satisfied that the story had concluded while leaving the impression of an open-ended world."

Surprise! Still can't write endings. It's okay Neal, it's what we've come to expect, and we totally love you anyway.

</comment><comment><USER11> I liked it, but I am a big Stephenson fan. I skipped Anathem and the baroque cycle books, but Diamond Age is one of my favorite books and I also like Snow Crash and Cryptonomicon a lot.

Reamde was pretty good, and this is an interesting setup.

Edit: Anathem not Anathema (thanks __david__ and lmm)

<comment><USER12> Reamde was very mediocre compared to the ones you skipped.

<comment><USER11> I enjoy the plot where multiple groups converge on a single location to get their hands on some key object. It's the same structure as two of my favorite movies: The Fifth Element and True Romance. When the groups are stereotypes as in True Romance, I find it even more entertaining. Reamde had all of that: bikers, anti government mountain people who are armed to the teeth and gangsters from multiple foreign countries :-)

I'll see if I can check out Anathem at some point, but Baroque is really too much of a commitment for me. I'm a slow reader.

Edit: Anathem not Anathema (thanks __david__ and lmm)

<comment><USER13> Anathem, not Anathema.

Books I've liked recently that have done that sort of thing: Rainbows End, or if you're willing to venture a little further in genre then Stardust (by a different Neil).

<comment><USER14> Rainbows End is amazing.

</comment></comment></comment></comment></comment><comment><USER12> Warning: publishing date is May 19th so you'll be left hanging for a month if it sucks you in.

<comment><USER15> That reminds me, I really hate how they start promoting books a few weeks before they are released. I see the promotion, and then when I go to buy it "pre-order" ??!?! Like it isn't a fucking yacht, I give you the money you give me the book, I'm not interested in a more complicated transaction. I'd be happier if they did the promotion during a time frame where I could actually buy it.

<comment><USER16> You can buy the ebook. It'll just magically appear on my Kindle on release day.

<comment><USER17> Same as pre-order I suppose. I suppose his complaint was that don't build the hype unless we can get hold of it. It's like Nolan's movie teasers which end with "Summer, ++Now.Year()".

</comment></comment></comment></comment><comment><USER18> At a guess the moon will turn into a ring surrounding the earth in the longer term, curious how it will continue.

<comment><USER19> It will turn into a cloud of asteroids surrounding the earth intended to prevent the human race from unleashing whatever hell we create with those autonomous mining robots on the ISS (would be my guess, at least). Feel like the agent/patient distinction is pretty blunt foreshadowing against it being a survival/resilience story against and abstract antagonist like a random natural disaster.

edit: [http://www.amazon.com/Seveneves-A-Novel-Neal- Stephenson/dp/0...](http://www.amazon.com/Seveneves-A-Novel-Neal- Stephenson/dp/0062190377) gives a bit more detail and it is likely it will not become a ring. Probably a lot of highly energetic reentrant debris capable of generating a lot of atmospheric heat.

edit: @jaquesm - i'm allowing for creative license, and was making guess explaining what would happened based on my gut feel for the plot direction. you're probably correct on the physics.

<comment><USER18> That's at odds with what I understand of the celestial mechanics of the earth- moon system, roughly the same thing happened to Saturn and even though the rings have thickness they are relatively thin compared to their width.

What reason would there be for the moon debris to form a cloud, that would require a lot of energy added to the pieces after the initial collision to get them to go into other orbits? (I'm sure Stephenson has researched this but it makes no sense to me at first sight.)

The options really are quite limited, re-unification in a 'lump', one or more large chunks escaping earth orbit or a ring, I don't see how a cloud is possible.

All but the second would result in quite a bit of debris landing on earth as the debris from the collisions would be scattered in all directions.

<comment><USER20> Energy was added, so I'm sure it will be a dynamic mess..

On the other hand, the moon is beyond earth's Roche limit so I don't think the final result will be rings.

Also what is the tensile strength of the center of the moon? I'm not sure it's possible to have 7 large non-spheroidal shaped pieces, but google suggests ~800 km is the lower limit for rocky bodies, so maybe it's just possible.

</comment></comment></comment></comment><comment><USER21> Oh right, this is coming out next month! He's going on tour to support the release:

[http://www.nealstephenson.com/tour.html](http://www.nealstephenson.com/tour.html)

<comment><USER22> Thank you for mentioning this. I would have likely never heard about the tour in time otherwise; an upvote isn't enough good karma for you, sir/madame!

</comment></comment><comment><USER23> The first time i read _Cryptonomicon_ it was a pleasure the whole way through, from page 01 to page >9000\. This may have been because it was almost entirely news to me; i had little to no experience with anything it covered. I finished it in 3-4 days. What a delight. Each reread i learn something new. Conversely, I went into _Snow Crash_ with high expectations only to find the story somewhat silly. Not that there weren't really great moments.

</comment><comment><USER24> 19th May will not get here soon enough. Always good sometime challenging but I never get sick of reading his books!!

</comment><comment><USER7> astronomicalbodiesformerlyknownasthemoon.com was registered by someone on 2015-03-12.

<comment><USER25> [http://www.nealstephenson.com/news/2015/04/13/seveneves- exce...](http://www.nealstephenson.com/news/2015/04/13/seveneves-excerpt/)

</comment></comment><comment><USER26> It's always so hard to read things on a dark background on a backlit screen. And especially looking at light backgrounds after that. Why is that?

<comment><USER27> I don't know, but the white text started sort of "flickering" between bright and dark after a while; a paragraph might look pretty bright, then it would suddenly seem darker again while the paragraph above looked brighter. It messed with my head and eventually I had to stop.

<comment><USER28> The gradient in the background might have had something to do with that. Also, low grade LCDs have obnoxiously extreme brightness variations from top to bottom that are most prominent in the mid-to-dark grays.

<comment><USER27> Ah, but this is my big fancy expensive Dell screen at work... I think it was a combination of the webpage and my brain flipping out.

</comment></comment></comment></comment><comment><USER29>
         "Not now, Pa, I know the moon's pretty, I'm right in the middle of debugging this method . . ."

</comment><comment><USER30> My eyes... dear god. Everywhere I look I see false images of letters.

</comment><comment><USER31> _The moon blew up with out warning and for no apparent reason._

TIL that "with out" is two words.

(I mean, seriously. How do you screw up your _very first sentence_?)

<comment><USER32> It appears to be fixed.

</comment></comment><comment><USER33> my eyes

</comment><comment><USER34> jesus god, what awful typesetting

<comment> grey-area The entire body is letterspaced and bold, that's the main problem. If you're in chrome you can edit styles on the fly, so try adding:

        letter-spacing: 0;
        font-weight: 300;
        line-height: 1.5em;

<comment><USER35> Cabin, which if I'm reading the CSS properly is what he's using, isn't a bad typeface. (Humanist sans serif related to Gill which I rather like.) But the spacing and weight--combined with the white on black--are really awful.

</comment></comment></comment><comment><USER36> Man, no kidding. It feels like a very inelegant info dump. While I realize those tend to show up in Stephenson books at some point or another, it's a rough way to start. I liked a lot about Anathem but found Reamde unmemorable. I'd love to see a return to form

</comment><comment><USER37> I appreciate his consideration in saving me a future time investment. Plus everyone else now gets moved up a slot on the library reserve list. A win-win.

<comment><USER38> Wow, what a horribly self-righteous way to tell everyone about your personal tastes. I feel enlightened already.</comment></comment>


Quick Overview: CSS Positioning - <AUTHOR> http://www.runtime-era.com/2013/03/quick-review-css-positioning.html

<comment><USER2> Well Explained.

Some Doubts * What is the default position of body tag? Static or relative ?

* In absolute position "the position context can be changed by giving the parent container a non-static position" So the parent should be immediate parent or any parent will work ?</comment>


I Hate My Role Models: 1 Min Read - <AUTHOR> https://medium.com/@JumpComet/i-hate-my-role-models-ba04be71d9ef

<comment><USER2> You look at role models as competitors. Which ultimately while they may one day become. The purpose of a role model is not to compete with you but to give you a different lens which you may view a problem.

The ultimate failure of these people is irrelevant, nor implies a glass ceiling. Since as with most error checking models. The more agreement between yourself and your role models, the greater the chance you'll execute that decision.

What I'm saying is who you set up as a role model, should be somebody who academically and morally challenges your opinions. Makes you question your own convictions and yourself. Ultimately a role model doesn't have to exist in this role.

The role model, simply exists as a unit test on your decisions. To check if your reasoning is sound enough. Your emotional relation to a unit test is irrelevant.</comment>


60+ recordings of Satie's Gymnopedie One played simultaneously - <AUTHOR> http://cookingwithsound.com/whats-even-more-beautiful-than-saties-gymnopedies/ <comment><USER2> This is really interesting, although I found it difficult to listen to, as I have spent a lot of time listening to the original. If I try to mentally block this from being connected with Satie's Gymnopedie, I enjoyed it much more.

That's not true for all classical remixes. William Orbit's version of Barber's Adagio for Strings is one of my favourite dance tracks.[0] (although not the Tiesto remix).

If you like Satie's Gymnopedies, then I also recommend his Gnossienes[1] and Faure's Pavane.[2]

[0] [https://www.youtube.com/watch?v=VIbIHxKh9bk](https://www.youtube.com/watch?v=VIbIHxKh9bk)

[1] [https://www.youtube.com/watch?v=CYH5xh6gd0c](https://www.youtube.com/watch?v=CYH5xh6gd0c)

[2] [https://www.youtube.com/watch?v=_tQ36TFvNoM](https://www.youtube.com/watch?v=_tQ36TFvNoM) (this recording played by Faure. Many modern recordings are at a slower tempo, such as this short orchestral version from the Berliner Philhamoniker conducted by Simon Rattle: [https://www.youtube.com/watch?v=HhiVuIRw4tM](https://www.youtube.com/watch?v=HhiVuIRw4tM))

<comment><USER3> I like Brian Eno's Discreet Music [1], which provides three slowed-down variations on Johann Pachelbel's Canon in D Major (the first one rather amusingly named Fullness of Wind), eventually reaching tempos where you can hardly discern the original melody.

Max Richter also brilliantly "recomposed" Vivaldi a few years ago, turning his Four Seasons into something like a modern work.

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

[2] [https://en.wikipedia.org/wiki/Max_Richter#Recomposed_by_Max_...](https://en.wikipedia.org/wiki/Max_Richter#Recomposed_by_Max_Richter:_Vivaldi.2C_The_Four_Seasons_.282012.29)

</comment></comment><comment> david-given This reminds me of one of the greatest pieces of ambient music of all time --- Justin Bieber's _U Smile_. It's old hat now, but just in case someone hasn't heard it...

[https://www.youtube.com/watch?v=bidHnEekXpE](https://www.youtube.com/watch?v=bidHnEekXpE)

<comment><USER4> 14x slowdown of Swede Mason's "Jeremy Clarkson Beatbox" ([https://www.youtube.com/watch?v=RY9u0LxIWJk](https://www.youtube.com/watch?v=RY9u0LxIWJk)) makes for some epic dark ambient.

[http://rjp-hosted-files.s3.amazonaws.com/dark_ambient_clarks...](http://rjp- hosted-files.s3.amazonaws.com/dark_ambient_clarkson.mp3)

<comment> david-given I'm only a little way into this but I could _swear_ this is the Planescape soundtrack.

Thanks!

</comment></comment></comment><comment><USER5> I opened and played this while opening this second and started to read

[http://www.neverendingbooks.org/artisanal- integers](http://www.neverendingbooks.org/artisanal-integers)

Work strangely well.

AFAIK might work well with any HN story

</comment><comment><USER6> Artist's webpage: [http://www.heyexit.com/](http://www.heyexit.com/)

</comment><comment><USER7> Wonderful, I've got to listen to this when I've got more time.

How did mankind survive before SoundCloud? Experiments like this music would probably have been a hard sell in those dark ages (except when you're John Cage).

<comment><USER8> Putting a link to an MP3 on a website is not that hard.

</comment></comment><comment><USER4> Stands up surprisingly well as a piece of music in its own right.

</comment><comment><USER9> Reminds me of Vangelis' Blade Runner soundtrack. Fascinating audio texture.

</comment><comment><USER10> This is incredibly beautiful.</comment>


The 10 Dumbest CEO Remarks of All Time - <AUTHOR> http://www.inc.com/ss/geoffrey-james/10-dumbest-ceo-remarks-all-time?cid=ps01902innovate

<comment><USER2> I really hate articles like this. This isn't buzfeed, and it doesn't culture anything.

</comment><comment><USER3> I can't read this article without registering with their site, or am I missing something?</comment>


Why Steve Jobs is (Legitimately) Pissed at the Media - <AUTHOR> http://www.theangrydrunk.com/2010/07/16/why-steve-jobs-is-legitimately-pissed-at-the-media/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+TheAngryDrunk+%28The+Angry+Drunk%29&utm_content=Bloglines <comment><USER2> He may be pissed at the media for "blowing things out of proportion", but it seems to me that he spends most of his time trying to get the press to blow things out of proportion to his benefit. Live by hype, die by hype.

<comment><USER3> Funny sense of desert you've got there. Being good at marketing doesn't mean you deserve a shitstorm of FUD and anger, the vast majority of which isn't even coming from iPhone 4 owners. And while you've decided to focus on how Steve Jobs benefits, you've neglected to mention how those of us who actually use Apple products benefit. There's a reason their stuff constantly gets the highest consumer satisfaction ratings and accolades from all over. No other computer company even comes close.

And if you actually knew anything about Jobs, you'd know he spends most of his time agonizing over design, not scheming over ways to build hype.

<comment><USER2> Sorry I touched a nerve. Are you his brother-in-law or something?

I use Apple products, and like them. However, statements like _No other computer company even comes close_ are the kind of hyperbole I'm speaking of. It's not false, it's just "blown out of proportion." Similarly, the antenna problem is not false, either.

Apple's design is great--equaled only by their branding, dating back to the "1984" days, about the "revolutionary" aspects of their products. Again, not false, just blown out of proportion.

Coincidentally, a friend just wrote on Facebook about 'a company that doesn't pee on my leg and tell me it's the "most revolutionary rain storm ever!"'

I stand by what I said: live by hype, die by hype.

</comment></comment></comment><comment><USER4> I can relate to this bit "More than once in my career I've been in a situation where something has gone wrong, sometimes catastrophically wrong. During situations like that, when every available hand is on deck trying to fix the problem, the most enraging thing in the world is a chorus of people who have no data, no real understanding of the issue, or even an understanding of the principles involved with the issue demanding answers NOW!"

It's frustrating when people in the company point the finger of blame without the data to back it up. Development teams are often those who suffer from this the most as they are where the buck stops - e.g. after a major software release there are issues that might be caused by installation errors/poor implementation/poor support response/user error but development get immediately blamed on 'poor product'.

I like that Jobs went down the whole clearly presented 'hard data' route to try to get to the heart of the problem; this is a good lesson on how to defend from criticism from those without knowledge of the real issues.

<comment><USER5> Mind you, hard data without even the possibility of independent verification, delivered far too late and after a string of PR blunders. Apple didn't __just __screw up, they kept screwing up by not respecting their customers enough to admit the problem early and giving much-needed data. Instead, they went down the route of being condescending and insulting to their customers ("you're holding it wrong"). That fierce Apple fanboyism that enables the company can rather severely backfire if Apple forgets, as it has done throughout the iPhone's short history, that their customers are intelligent human beings capable of making their own choices and coming to their own conclusions.

<comment><USER6> In what way has Apple forgot that their customers are reasoning individuals? I don't see how you come to that conclusion in this case, but you seem to argue that this has happened before?

<comment><USER5> Well, by their behavior with respect to pornographic or erotic apps, their response to jailbreaking, their decision to completely lock the device against unauthorized apps, and their censoring of books and comics over non-sexualized nudity. From the very beginning, Apple has demonstrated a near complete dismissal of their customers' ability to make decisions for themselves, as can be seen from their decision to make a walled-garden sort of marketplace where customers can play around without getting hurt.

<comment><USER6> With respect, I think a lot of reasoning individuals who are Apple customers like or are at least indifferent to the walled garden approach. Just as those saying that they get better reception from the iPhone 4, or saying nothing at all like or are at least indifferent to the antenna design.

It seems that many critics of the walled garden approach as well as the antenna design have a hard time realizing (or conveniently forget) that those not complaining loudly aren't necessarily mindless drones who buys anything with an Apple logo on it.

So in my mind, I'd say that there are huge amounts of intelligent, reasoning individuals who are using the iPhone 4 at the moment who like the phone as it is. So while I agree that they should have done more when it comes to telling the world they were on the case, even though I doubt it would have helped much, I think your image of how badly Apple treat their users is vastly exaggerated.

</comment></comment></comment></comment></comment><comment><USER5> I don't think Jobs' anger is legitimate at all. Yes, all phone have problems, and sometimes the media misreports on them (look at the DroidX/eFuse story, for instance). What's different, however, with Apple's iOS platform, is that there's only two choices available to consumers: use an iPhone 4 or use an iPhone 3GS. By narrowing the market so dramatically, Apple makes otherwise forgivable flaws into acute failures. If you like to hold your phone differently than how Apple thinks you should, then too bad-- that's their only current-gen phone. I think that, more than anything, is what legitimizes turning an otherwise minor issue into a complete shitstorm.

The antenna problem is one __forced __on consumers of iOS devices, including those consumers with a significant amount of money invested in paid iOS apps that can't leave the platform without leaving those behind. The antenna problems illustrate why buying an iPhone is always a losing deal: the consumer has no choices other than those Apple explicitly allows. Now if only people reacted so strongly to the horrendous lockdown of the iPhone and of the App Store.

<comment><USER7> _If you like to hold your phone differently than how Apple thinks you should, then too bad-- that's their only current-gen phone._ Or you can get their free case, which leaves it still thinner and arguably better looking than most other phones on the market.

 _The antenna problems illustrate why buying an iPhone is always a losing deal_

That seems _really_ hyperbolic... _always_ a losing deal? Unless perhaps you assume that the portion of critical-problem-havers is 100%. In actuality, it's a tiny fraction. (And, of that tiny fraction in this particular case, the vast majority can be solved with the free case.) Could Apple someday be struck by the inability to make a good product, leaving users with no upgrade path? I guess so, but that doesn't keep me from buying what appears to be for me easily the best device on the market. If that ever changes, yeah, I'll have to find replacements for maybe $50 worth of apps. Not the end of the world -- it's not like I'm signing on me and the next few generations to Apple-only.

<comment><USER5> To start with, the free case is a very recent concession that was made in response to intense media pressure (whether deserved or not). Moreover, I didn't say that the antenna problem is a critical problem for all users, but I said it illustrates why for all users, it's a sucker deal. You are betting against Apple ever deciding that its one sanctioned upgrade path should go in a direction you don't like. You are gambling not that Apple will suddenly be unable to make good products, but that their design decisions will be different from your needs and desires. Moreover, there is likely a lot more investment in the platform than just $50 of apps.

As for "easily the best device on the market," that's only true if you are completely fine with a device that does only and exactly what Apple allows it to do, rather than a device that is, as computers throughout their entire history as successful consumer devices have been, designed to allow you to do what you want-- including create and innovate. Compare the approach of Google's App Inventor to the approach of Apple's monolithic and cryptographically signed dev chain, for one specific example of what I mean.

<comment><USER7> I understand what you're saying, but the vast majority of people who have iPhones (and the people who Apple is explicitly targeting with their product design and marketing), are completely fine with a device that "does only and exactly what Apple allows it to do".

So to say that "for all users it's a sucker's deal" is to ignore these millions and millions of people while making a statement about yourself and your tastes and desires. For you, apparently the iPhone's tradeoffs are unacceptable, and that's fine. I'm sympathetic with what you're saying: in theory, it sounds obvious that an open ecosystem where every device manufacturer can create whatever they want is going to lead to better hardware than Apple could ever compete with. In reality, that just could not be farther from the truth for a huge group of people: there's not another phone I like better than the iPhone 4, so I'm "stuck" with Apple — not because they have me locked in but because nobody else seems to make a phone whose particular tradeoffs are more in line with what I desire.

</comment></comment></comment></comment><comment><USER8> _I think that he's expressing his dismay over how the press, in the complete absence of any actual hard evidence, blew this issue completely out of proportion_

In a crisis situation you have to play defense. The burden was on Apple to provide the hard evidence. When they determined it was going to take some time to gather this information they should have communicated a time table. That being said it's totally surreal that we live in a world where the iPhone has become so important that it gets a level of mainstream media coverage usually reserved for death & destruction so it's probably understandable that Apple wasn't prepared.

</comment><comment><USER9> Lets not forget some points:

1\. iphone4 looses more connections than iphone 3 as stated by Steve Jobs himself. 2\. despite irrational iphone fan people no other smartphone has a magic spot to hold to decrease phone call connection success. If you doubt me try it on iphone3gs..no magic spot whatsoever.

3\. apple thinks its a problem and has hired extra hardware antenna engineers to review the problem.

The only legitimate things Steve Jobs should be pissed at is Apple's performance on this issue. Back during the 1990s we had this Apple that ducked responsibility for product design execution mess ups and Apple paid the price both in lost sales and stock price performance.</comment>


Packrat Parsing and Parsing Expression Grammars - <AUTHOR> http://bford.info/packrat/ <comment><USER2> I kind of really dislike the tendency to conflate PEG and packrat parsing. Packrat parsing is not a required feature of PEGs, and many of them don't use it.

Further, many implementations of packrat parsing are absolutely dog slow because they simply memoize every term, which is basically trading a high complexity in steps for a high complexity in space, so allocation pressure and cache pressure can both become very bad, especially for large inputs and/or large grammars. To me it's almost a defining case of complexity notation being utterly misleading in practice.

This paper reflects my experience: [https://mercurylang.org/documentation/papers/packrat.pdf](https://mercurylang.org/documentation/papers/packrat.pdf)

</comment><comment><USER3> I've used PEGs to create a compiler, and it results in clear, readable code, easy to maintain. Because the parser structure it's cleaner, it feels natural to write the parser manually with PEGs. The key is to handle parse-fail with exceptions. Instead of having a syntax-file and a generated parser, the code is clear enough to act as low-level documentation. see: [https://github.com/luciotato/LiteScript](https://github.com/luciotato/LiteScript)</comment>


Start-ups and Emotional Debt - <AUTHOR> http://www.evanmiller.org/start-ups-and-emotional-debt.html <comment><AUTHOR> "I realize that many people who do successful start-ups say it was the best thing that ever happened to them. But they've also become different people, and they are not the same people they would have been if they had decided to pursue another course. They have different sets of relationships, different skills, different attitudes, and different desires. They really have no idea what kind of person they otherwise would have been become."</comment>


How to Deploy Software - <AUTHOR> https://zachholman.com/posts/deploying-software <comment><USER2> One thing this glances over is that you should have something monitoring your production systems to make sure that they are running correctly.

To start with get something to monitor errors/exceptions and email you. To name a few services:

[https://airbrake.io/](https://airbrake.io/)

[https://rollbar.com/](https://rollbar.com/)

[https://github.com/errbit/errbit](https://github.com/errbit/errbit) (can be hosted on Heroku for free)

Also make sure that you have accessible logs that log useful information (timestamps, the user making the request, unique request ID). Then use syslog or a SaaS service to aggregate logs from all servers in one place, and keep them for as long as you can.

<comment><USER3> Shameless plug, but my co-founder and I are about to launch our powerful logging service this month. One of our features is session-specific logs and the ability to send alerts at user-defined thresholds.

We'd love to get some feedback on our product when we launch to beta, so if you're interested, please sign up for our email list at [http://logdebug.com](http://logdebug.com)

<comment><USER4> One suggestion is remove the "Most Popular" banner above Small Business on your pricing. Being as your site is plastered with under construction, it's a turnoff seeing such false advertisement.

<comment><USER3> Sure, good tip.

Though the pedantic butt-head in me wants to point out that out of all of our paying customers, they're all using that level of service. :) So technically...

<comment><USER5> So keep it. Ditch the under construction stuff instead if you have customers.

</comment></comment></comment></comment></comment><comment><USER6> I really enjoyed this article. As an industry, when it comes to something essential like source control, we seem to have converged to a common set of practices and workflows. Deployment is arguably just as important, but I think the practices are very different on different teams. This article is like a more practical version of Continuous Delivery.

Three areas that I think would have been worth including:

1\. Pre-production.

You deploy to test & other pre-prod environments more often than prod. They should use the same scripts/tools/processes as production deployments, only with different permissions.

2\. Configuration.

Test and production environments will always have different config settings, so no team will ever be able to deploy to more than one environment without encountering this problem. I think there's still an open question around whether those configuration settings should live in the same source control as the code, in a different source control repository, or a dedicated system. Source control systems and sensitive values (passwords, API keys, etc.) don't always mix.

3\. Build your binaries once.

The article is more focussed on dynamic languages, but for compiled languages, I think this is important. If you branch, compile, deploy to test, test it, get the all clear, then compile again and deploy to production, there's a lot of opportunity for differences between what you tested and what goes to production to sneak in.

In fact even for dynamic languages, this might be a valuable practice. What if the JS minifier on one build server is different to another, and the deployed script ends up being different in production to what was tested.

Disclaimer: I'm the founder of Octopus Deploy, and these practices might be biased towards enterprisey .NET/on-premises deployments rather than cloud hosted, dynamic language projects.

<comment><USER7> _1\. Pre-production_

Pre-production should test production in a non-production environment. Specifically, if a system connects to, say, SalesForce, and you've been using a local sandboxed instance of SalesForce in dev and UAT, the pre-prod should connect to the real, live SalesForce. I have a pre-prod environment for my current project, and it's useless because org policy states that only prod environments can connect to live instances of anything. Completely invalidates the reason for having pre-prod.

 _2\. Configuration ...will always have different config settings..._

Yes, aside from pre-prod. Pre-prod and prod MUST be mirror images, INCLUDING config settings. Identical. The same in every way except for host names.

<comment> UK-AL We use octopus deploy(Great software btw), most people use configuration stuff mostly for connection strings. Everything else is the same.

</comment></comment></comment><comment><USER8> In theory, feature flags seem like a good idea. Until you reach a point where too many flags become difficult to test in an exponential tree of combinations. Also, it demands tight discipline to make sure each new flag properly isolates some new feature ... Has someone had success with this idea, and be able to 'tame' an explosion of flags in their codebase? really curious

<comment><USER9> On my team of about 10 devs, we create / destroy about 5-8 feature flags a month.

The only thing you have to remember is: Its either going to production, or its getting dropped.

There is an expiry date built into the feature flags framework (90 days), and either they need to be explicitly cleaned up and deprecated, or extended with a valid reason attached.

Also, we code review every commit. If any diff is coding around/through a feature flag, the first question is always: "Can you clean up that experiment first?"

<comment><USER10> Sounds very familiar. Are you in Seattle?

<comment><USER9> Something like that, yeah

</comment></comment></comment></comment><comment><USER11> > Deploying major new features to production should be as easy as starting a > flamewar on Hacker News about spaces versus tabs

Great writing. Spaces all the way.

<comment><USER12> Would someone mind explaining the argument for spaces over tabs? Possibly naive young dev here.

<comment><USER13> How many spaces do you like to indent your code? Some people like 3 space indentations, some like 8 spaces, and some like 5. It's very personal (but anyone who doesn't use 3 is a reeky brazen-faced mammet).

A simple solution is to use tabs, because then every developer can set the tab distance however they like, and they are happy. It breaks down when you have code that is aligned beyond the indent, like this:

      if(a && b &&
         c && d &&
         e && f   ) {

In that case, increasing (or decreasing) the tab distance will ruin the intention.

The best solution is to use tabs to the point of indentation, and then spaces thereafter, but a lot of code editors don't support that, so in practice it's hard to implement, so people use spaces to preserve their formatting when it gets uploaded to github.

<comment><USER14> Mixing sounds like the worst option.Its what has cause horrendous looking code in the past when you open someone elses code and they are mixed.

Python and spaces for me.

<comment><USER13>
      > Python and spaces for me.

Sounds like you are a very open-minded individual. Not.

<comment><USER14> I say this from experience, not narrow mindedness.

Open a file where it is all spaces, and it looks the same on every machine. Open a file with a mix of spaces and tabs, and it often turns out an absolute mess.

</comment></comment></comment></comment></comment></comment><comment><USER15> Does anyone else work on systems that take 3 hours to back up the DB, an hour to deploy, 1 hour to start up and a few hours for users to check out functionality before business opens on Monday? No to mention the federal regulations about what paperwork is required and who can even access production. Maybe I'm in the wrong site.

<comment><USER16> Hah, we (hopefully!) get an update window every 18 months! And a staging a new production like test environment starts with another $100K invoice..

And thank goodness Microsoft hard-coded in a 10 hour delay to ensure the KDS root key of a domain is propagated, even if I create it before I create additional domain controllers...

Such fun!

<comment><USER17> Off topic, but to create an immediately effective KDS root key, just set the effective time ten hours in the past. You can validate propagation by looking for the 4004 event in the KDS event log. This is probably not a good idea in production, but is useful when building/rebuilding a lab.

      Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

See [https://technet.microsoft.com/en- us/library/jj128430.aspx](https://technet.microsoft.com/en- us/library/jj128430.aspx)

</comment></comment></comment><comment><USER18> The post is interesting, but it doesn't mention two major difficulties: zero downtime deploys and database migrations.

<comment><USER19> We use django migrations, and I still haven't found a way to do zero downtime deploys and migrations short of doing the following:

If we are trying to deploy migration #1, first deploy a version B of the code that supports (but provides the same set of features as before) the db both after migration #1 and before migration #1 (maybe with the help of a feature flag that is set in the migration). Do the migration. The deploy a version C of the code which removed the feature check above. But all this requires 2 different versions of the code and a lot of process just to ship out one migration. It gets combinatorically worse if you have more than one migration to deploy.

<comment><USER20> I wish there was a way to "pause" incoming requests in web servers. Most deployments (migrations + code) take less than a few seconds, and I'd be fine with some users having to wait 2 seconds for a request to finish over their request hitting a 500 (due to inconsistent code/database) or 503 (putting the site into maintenance mode).

<comment><USER21> Usually we aren't deploying a schema change that's really huge so we just go for it and let the application crash for those users who happen to hit a place where the code/schema are out of sync.

Zero (no crash) downtime deployments seems like too much effort for too little gain.

<comment><USER22> Agreed. Seems like a case of optimization for technical completeness rather than a business need.

</comment></comment></comment></comment></comment><comment> UK-AL We have something similar. But I don't like branches, I prefer single trunk development(generally agree with Martin fowler) + feature switches to isolate wip features. We store all binaries built. so we just roll back to the previous binary, which is a single button click for us.

<comment><USER23> Curious... Why don't you like branches?

<comment> UK-AL [http://martinfowler.com/bliki/FeatureBranch.html](http://martinfowler.com/bliki/FeatureBranch.html)

It's a controversial article though.

<comment><USER24> I'm pushing for toggles on my team, haven't made a single feature branch in this repo resulting in no merge conflicts (yay).

Sofar I'm the only one regularly doing it without feature branches. Running with the idea that just because you can branch cheap doesn't mean you should. Of course toggles are technical debt to be managed, but so are branches.

I've found good practice has been mentioning which toggles are available on the README with their defaults (could be generated)... they should be tracked and removed ASAP. I read a newer article that breaks them down into categories [http://www.infoq.com/news/2016/02/featuretoggles](http://www.infoq.com/news/2016/02/featuretoggles). Toggles over branches are showing value as we run different variants on staging without having to redeploy different builds, but instead changing a launch variable. It's especially clear with 2+ WIP features. We're using environ with Clojure which doesn't have any fancy runtime toggling, but that'd be another thing to look at.

<comment><USER25> The tech debt associated with branches disappears with the completion of the merge request. The tech debt with feature flags doesn't disappear until someone gets around to removing the (now) dead code.

Personally, I use both, based on what is best for the feature. Why not, after all?

<comment><USER24> I love branches in theory, but the main problem has been in practice around CI. It's a nightmare trying to manage a staging environment with feature branches involved... given better tools/a better build pipeline I'd go back. I agree, toggles are basically programs branches compiled in... analogous goto vs if/else control structure.

But day-to-day, stakeholders want to test feature X that they've heard is going well but it's not stable enough for develop? Okay, let's [engineering time and $$$]. vs. adding FEATURE_NEWDB=true to the upstart script. We've already got automation engineers helping us out, but until the deployment problem is solved toggles are more practical in our case.

<comment><USER25> How hard is it to set your CI to run off a separate branch? Or to run CI for all branches which are checked into a repo (a common option I've seen implemented)

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> Nobody said it here yet, so I just wanted to mention that the design of this blog is really nice. I love the font, links, blockquotes and chapter title images.

It also rendered equally nicely on my android phone and my desktop browser.

I saw that the author has a github repo for an older blog style for jekyl, but I'd like to see a similar thing for this one.

Thanks

<comment><USER27> Thanks! Was thinking of open sourcing this soon as a one-off. I'll see what I can do. :)

</comment></comment><comment><USER28> "How to deploy _web_ software".

The software world > web servers.

(Sorry to be picky, but some people seem to assume that all software is developed for the web these days whereas the web world is just a significant & vocal minority).

<comment><USER14> A great deal of software is web based these days. You install apps on your phone or your desktop. You deploy to a server.

<comment><USER28> true, but its still a 'sizeable minority'. As far as number of deployments go, the embedded software world massively outweighs server, client, mobile and desktop.

Unfortunately (or fortunately), we in the embedded software world tend to be less vocal than the others.

<comment><USER14> I wouldn't have though deploy was the correct word for embedded.

If its one piece of software I would think of it as an install. If it's coordinating multiple pieces its a deployment.

</comment></comment></comment></comment><comment><USER29> Thanks for the writeup - very helpful. It's always good to get a view of how others are solving the same problems oneself has.

That said, the article does come off a bit as trying to be authoritative, but at the same time it doesn't leave enough room for possibilities where alternative approaches may have merit as well (i.e. "this is how to do it" vs. "what worked well for us, ymmv"). Newbies that read this article will think that the principles described are the canonical way and even try and apply them in scenarios where alternatives may prove superior.

Other than that, a lot of good advice, well done!

</comment><comment><USER30> I've been arguing for using Git Flow. Reading the post I have to say the stand our lead takes against Git Flow and in favour of very cosy CI is perhaos steonger than I realised.

He argues for pushing about as often as possible. With our small team thats very do-able, every push gets tested and linted by the 'blue' or 'green'. You're supossed to only push passing code which you easily can by running the tests and lint locally. So instead of all the pain points mentioned in the post you write passing code, pull and rebase on other passing code, and then push. Little code review, no worries about hasty reverting, few / early conflicts keeping us from trilling each other up or writing incompatible features.

The reason I argue for Git Flow? Our tree is an absolute mess. Most often a single chain, of often linearly scrambled features. In other words removing one feature would be hard and require a bunch of legwork, not a couple Git commands.

If anyone strongly feels there's a better way for a small team than lightning fast CI let me know!

</comment><comment><USER31> I wish native Nodejs deployment was a solved problem, but there really is no comprehensive and universally used tool for deploying Nodejs using Nodejs. ShipIt mentioned in the article is barely a year old, it has a short featurelist and short list of users. PM2 (Keymetrics) is not bad but is buggy, also they seem a bit overwhelmed at the moment. Flightplan is decent but the syntax is more awkward than ShipIt. Every other common language has a stable deployment tool besides Nodejs.

I ended up going with Distelli, it's a SaaS but it's fantastic. These days deploys often involve more than just one app or language, and I really prefer a tool that can ship anything. Also, having a GUI to see deployment statuses is invaluable. With those requirements none of the Nodejs tools can stand up to the other, more mature utilities. And rather than have to write all my deploy logic in another language, I just purchase the service.

<comment><USER32> What issues have you run into with PM2? I'm running it in production myself, so I'm curious.

<comment><USER33> I've really enjoyed working with PM2 in production for the last 4 months... although our ramp up has been slow.

</comment></comment></comment><comment><USER34> I'd be interested in hearing people's thoughts on deploying feature branches to production before merging them. I've generally followed more of a git-flow approach [1]. This seems to have the advantage that multiple feature branches can be grouped and deployed together - thus, avoiding the problem in the article of the deploy queue becoming a bottle neck.

[1] [http://nvie.com/posts/a-successful-git-branching- model/#crea...](http://nvie.com/posts/a-successful-git-branching- model/#creating-a-release-branch)

<comment><USER35> > multiple feature branches can be grouped and deployed together

I would respectfully argue that this is not a desirable feature.

Although you might save some time by deploying multiple branches at once, you cloud the waters of what and how to roll back.

I think a better idea is to make deploys easy, quick, and revertible so that you can deploy early and deploy often, and in the event of a rollback, you can rollback just the broken feature.

<comment><USER34> That's true but it would seem like there would be other disadvantages to.

For example, when do you do testing? If we test as soon as the pull request is opened, we know that master is going to change a lot between now and when we finally deploy this code so the tests might not be valid.

If, on the other hand, we wait to test just before we deploy to live we risk locking up the queue for too long. This might not be an issue if you're test only take a couple of minutes to run but if you have lots of integration tests (like facebook for example [1]) then it could become a big issue.

Is the solution to this, you just accept that the codebase you're testing won't exactly be the same as what's deployed to production and the risk that comes with that?

[1] [https://developers.facebooklive.com/videos/561/big-code- deve...](https://developers.facebooklive.com/videos/561/big-code-developer- infrastructure-at-facebook-s-scale)

</comment></comment></comment><comment><USER36> Why worry about what is on master, if you save your build artifacts. so that if you need to go back to a the previous behavior, just redeploy the previous _productuon build output_

<comment><USER37> You code is written in golang. You've been compiling it with golang 1.5.1. Then golang 1.5.3 comes out with critical security fixes for their TLS code.

That is why you care what is on master: because you need to rebuild if your runtime changes.

<comment><USER38> We deploy straight from master, but tag each build.

If you need to rebuild a specific version, it's as easy as checking out the tag.

<comment><USER39> This feels like the correct strategy to me (and it's what we do too). Deploying many branches to production seems like a nightmare at any scale.

</comment></comment></comment></comment><comment><USER40> Interesting article. Frank and honest. Good to read the experiences of others.

To get the disclaimer out of the way I'm a co-founder of Vamos Deploy. Our product addresses many of the deployment problems that have been discussed here so I thought I'd mention it. We are looking for feedback on the product and an early adopter or two - [https://vamosdeploy.com](https://vamosdeploy.com)

I'd like to cover some techie details here. Vamos Deploy encapsulates an application with it's dependancies and runtime config so it can be deployed as one to any number of machines irrespective of the OS (well, Linux and Windows at the moment). This encapsulation is achieved by configuring a 'grid' with all the application package versions, library/runtime dependancies, runtime property values and local repository names (hostnames usually). When the grid is deployed (all via CLI) the respective local repos get updated. You can have multiple grids on a host (in a local repo) thus enabling multiple, differently configured, encapsulated applications that don't conflict. It avoids duplication by the grid sharing the underlying application packages and libraries in the local repo. There is a audit log of all actions for traceability and transparency. A simple ownership model prevents non-prod code getting into production and restricts who can deploy to production. It can be combined quite easily with any config management tool for release orchestration. You don't need RPM/Deb packages or deal with Yum repos. We have concentrated on making it easy to learn and use so max benefit can be attained quickly.

I'll stop there. Be interested in anyones feedback here or [https://vamosdeploy.com#contact](https://vamosdeploy.com#contact) for a chat.

</comment><comment><USER41> The title of the article was "How to Deploy Software", but almost all of the advice only works for server side software where you have total control over the deployment environment.

I'd be much more interested to learn about how people develop mobile and web apps, where feature flags are far less useful as you need to push the entire app to the AppStore, so your iteration time is much slower.

</comment><comment><USER42> I also recommend Zach's presensation [https://speakerdeck.com/holman/how- github-uses-github-to-bui...](https://speakerdeck.com/holman/how-github-uses- github-to-build-github) [selfpromo:] When we were thinking about deploying our frontend builds, we got inspired by Ember's CLI Deploy pipeline ([http://blog.firstiwaslike.com/deploying-ember-cli- apps/](http://blog.firstiwaslike.com/deploying-ember-cli-apps/)) and we've built something similar for our Webpack based app ([https://github.com/productboard/webpack- deploy](https://github.com/productboard/webpack-deploy)). Together with Git flow methodology we basically removed all friction from deploying new versions. Would love to hear your thoughts!

</comment><comment><USER43> I don't know if I agree with the branch on every deploy particularly if you have a small team and use Mercurial where named branches live forever. I wish the article discussed dependency management more.

Instead of branching we tag every deploy and use dependency management heavily (ie maven, npm, etc). That is the project that gets deployed never really has any branches but is composed of lots of smaller projects each in their own repository which may have branches but they have to be released.

This approach cuts build time, improves coupling/cohesion as well as facilitate a possible transition of OSS useful components (that do not provide a competitive advantage nor or proprietary).

I have seen way too many projects that have this giant monolithic source tree (particularly PHP projects) and thus have to rely on branching much more heavily. I firmly believe this is the wrong approach.

</comment><comment><USER39> > When you're ready to deploy your new code, you should always deploy your > branch before merging. Always.

Does anyone actually do this? This seems counterproductive - what if there are multiple branches?

<comment><USER44> Assuming you have a product/release branch and many others, then I'm guessing the author means you should merge product into your own branch and deploy that, before merging your branch back into product (and deploying it).

That should work fine with multiple branches in most cases, so long as you have a system to stop anyone else deploying their branch while yours is running.

</comment></comment><comment><USER45> I use deploynaut as my deploying tool, and I have to say it's made the process much smoother. Previously I'd simply use git to update a code base or sql workbench/pgadmin to update a database.

</comment><comment><USER46> The body text in this article is illegibly thin, please consider moving to weight 600 so that people can read your text. You've worked hard to write it, now it is time for people to read it. :-)

<comment><USER47> I didn't notice, but my NoScript blocked the web font and the default font is more legible with that color. In both cases changing the color from rgb(100, 100, 121) to rgb(80, 80, 100) is enough to improve the readability of the text. font-weight: 600 seems a little extreme.

<comment><USER48> For some perhaps the color of the text is the only complaint, but for me the font is also illegibly thin [1]. I got around it by disabling the web font, because just setting the font weight to 600 didn't fix the odd shapes [2].

The bold version of the font is also available as a separate font family (AvenirNextLTW01-Bold). It looks much more like a "normal" font weight and is incredibly readable [3].

[1]: [http://i.imgur.com/uVHXptR.png](http://i.imgur.com/uVHXptR.png) [2]: [http://i.imgur.com/IXwR6EU.png](http://i.imgur.com/IXwR6EU.png) [3]: [http://i.imgur.com/xgz7EtR.png](http://i.imgur.com/xgz7EtR.png)

<comment><USER47> I noticed that thin fonts are not so thin on high DPI screens. Example: that font is more readable on my 9" 2500x1600 (approx) tablet than on my 1080p 15" laptop. Maybe they are designing for retina Macs.

</comment></comment></comment></comment><comment><USER49> [http://spinnaker.io](http://spinnaker.io) : deployment software made by netflix (king of daily prod pushes), google, and the community for aws, gce, azure, etc

</comment><comment><USER50> shoutout to sublime for development

</comment><comment><USER51> I just double-click a command file on my desktop and I'm done.</comment>


Thinking of applying for a job at Google. Any tips or feedback on my résumé? - <AUTHOR> http://benhoyt.com/cv

<comment><USER2> I think that if you're going after a job in our field these days, you ABSOLUTELY should have a resume like this. Actually, it is less a resume and more a carefully crafted sales pitch for yourself. You can do so much selling it isn't funny -- links to your OSS contributions, etc. (I would have surfaced the code more quickly than you do in your resume, but this is a _very_ minor nitpick. Oh, and if you have a blog, you have at least one or two articles on it which are exemplars of your best work. Link those directly.)

My one suggestion is that your sales presentation says an awful lot about you and not that much about Google. That goes against pretty much everything I know about sales. ("But its a resume! It should be about me!" No, that is a meaningless tradition perpetuated by people who are much less savvy than you are.)

If I wanted to get a job at Google, I would make it obvious that I understand Google's business about as well as I understand Ruby, or better. Talk about how your experience with MicroPledge prepares you to deal with web-scale computing. (Even if it doesn't, demonstrate that you understand the differences.) Talk about how your e-commerce experience at Gifty gets you inside the head of Google's customers, and how you understand Internet advertising on a deep level because it determined whether you ate or not. (The truth that I advise you to keep at the foremost of your mind and not say out loud: _Google is an advertising company._ )

<comment><AUTHOR> That's really thoughtful feedback, thanks. I wasn't quite sure -- is your third paragraph an explanation of how to put your second paragraph ("saying a lot about Google") into practice?

<comment><AUTHOR> In any case, I've implemented your suggestions -- thanks.

</comment></comment></comment><comment><USER3> Looks like a nice resume. :)

The following feedback probably isn't google-specific, and it's really just nitpicking, but I would say:

\- "move to the U.S. for about two years in mid-2010". AFAIK, most employers (maybe not Google) would probably rather just hear "move to the US in mid-2010".

\- "Skills: I can... develop web applications". This section can be rephrased as "Skills: I have... developed web applications", etc. This is a job application tip I've had drummed into me, to always stress what you have done rather than what you can do.

\- It might sound better to slap a better title than "long-time friend" on your third reference. Maybe you two collaborated on a project at some point?

\- Hehe @ the Fermat reference. Nice touch.

Just my myopic 2c, and like I said it's really mostly nitpicking. :).

</comment><comment><USER4> I didn't see anyone else mention it (sorry to repeat if someone does before or while I write this).

But it REALLY helps if you have a friend who is already in there refer you. If you have none atm, either network or use [http://steve- yegge.blogspot.com/2008/03/get-that-job-at-goog...](http://steve- yegge.blogspot.com/2008/03/get-that-job-at-google.html)

Having a referral pretty much lets you skip the majority of the line at most companies. It also lets you get by even if your resume is not particularly stellar but your skills are. Google, in particular, makes an effort to do onsite interviews with most referrals (unless you disqualify yourself via a variety of different ways).

Having a friend there also means you get a lot of help along the way, advice about what to study for, hints, etc. So all around, its a good idea.

<comment><AUTHOR> Thanks for the link to that Steve Yegge post -- do you know if he's still batching up and submitting resumes as per the bottom of his post? Do you have any other suggestions for networking into Google (I don't know anyone directly who works there)?

<comment><USER5> Or ping me; I work there. :) (There are quite a few of us on HN, afaict.)

</comment></comment></comment><comment><USER6> Google likes to ask lots of algorithmic questions in rapid succession. At least they did when I interviewed. Knowing of a solution or library was not good enough (they seem to reinvent their own 'everything' anyway, perhaps for good reason?). If I wanted to work there, I would practice doing classic CS problems on a whiteboard in front of friends beforehand, it's much different than real life where you can look stuff up, mull things over a cup of coffee, take a walk, etc. They were in my face the whole time.

<comment><USER7> i second this. know basic data structures and algorithms. they are not going to ask you to implement red-black trees but they'll probably ask questions that require you to use hash tables or priority queues. know how to implement these and their running times.

and definitely practice solving problems on the whiteboard. its completely different. if its within the realm of comfort also get used to thinking out loud in the interview. some people really can't do this but i've found, both as an interviewer and interviewee, its really helpful.

your resume will basically get you a phone screen, beyond that i suspect its irrelevant.

(for the record, i've interviewed with the GOOG and was offered a job)

<comment><USER8> My friends have all had similar experiences, though most of them were interviewing straight out of undergrad, so it may have been a little different. Have seriously in-depth knowledge of the languages you claim to know, practice solving problems under pressure, and have a strong algorithmic foundation. They seem to have a reputation for being rude, but it's a competitive market and they're looking for the best.

Things are pretty similar where I work. We will look at most people if their resume lists the relevant technologies, but the phone screen and in-person interviews are very tough. There are so many liars out there that resumes aren't a very good filter. Even academic pedigree doesn't seem to count much in the software development world, though it counts more if you're doing more research-y/academic things like machine learning.

</comment></comment></comment><comment><USER9> The first thing that caught my attention was the bit about "U.S. born".

In the USA it is illegal to ask about country of origin (as well as age, gender, religious beliefs, marital status).

I've heard of hiring managers discarding CVs outright if they contain information that is illegal to ask about, though I have no idea what the practices at Google are.

Recommended reading: "Land the Tech Job You Love" by Andy Lester, published by The Pragmatic Bookshelf.

<comment><AUTHOR> Hmmm, interesting point. I wonder if it really matters. I put that there only so they know I'm a U.S. citizen and hence have legal right to work there. Can you suggest a succinct alternative?

<comment><USER10> _Can you suggest a succinct alternative?_

"Authorized to work in the United States." Yes, I am a lawyer, and I used to practice immigration law.

<comment><AUTHOR> Thanks -- I've updated it.

</comment></comment></comment></comment><comment><USER11> I'd be weary of plastering a cell phone # of one of your references all over the internet...

<comment><USER12> You mean _wary_. The person in question will be _weary_ of being called.

</comment></comment><comment><USER13> I'm late to the party, but I'll provide my two cents as someone who worked at Google and interviewed candidates (most engineers there are trained to do interviews):

1\. Your resume looks good and should get the recruiters attention, and

2) that's about all your resume is good for, in my experience. Interviewers will look at what you've done in the past to help decide what questions to ask, but your answers to those questions are far more important than your past experience.

As others have said, review your basic algorithms and data structures. Be prepared to write _correct_ code on the white board (not pseudo-code, at least not as your final product).

Finally, if things don't work out at Google - why not submit your resume to OpenX (<http://openx.org/jobs> or email me joel at openx dot org)? We're also hiring :)

<comment><USER14> Off topic, but there is no stylesheet loaded when accessing your website without a www subdomain ...

<comment><USER13> Were you using Chrome? In FF and Safari4 the stylesheets load regardless of whether or not there's a subdomain, but in Chrome I see the behavior you describe.

<comment><USER15> Stylesheets are not loaded for me either. I'm using FF 3.5.7.

</comment></comment></comment></comment><comment><USER16> Strip I, me etc. Time is of essence (resumes are not read but skimmed).

How about adding some things from business perspective? I mean when you talk about what you've done, it's good to know that you gained experience. But it would be even better if you could show where your efforts led. Like "redesigned shopping cart process, which reduced the number of support calls by XX %"

Watch out for ambiguous text: "the clean UI and weather graphs really made Harvest's product stand out." It's better to be able to say something solid like "new design led to XX % better user retention" or "new UI was awarded by XX".

I'd also advice against placing your education with the rest of "about me". Some might skip the whole chapter. This will not happen if education has a heading of its own.

I would also place "experience" just after the summary. Best stuff first.

</comment><comment><USER17> 500,000 lines of Python and SQL?

<comment><AUTHOR> Oh dear! Good catch, that's embarrassing. I did a recursive "wc" but then read the wrong column. It's only 21,000 lines. :-| Fixed now: at 21kLOC, is it still a figure worth including?

<comment><USER8> I don't really think so. You're really trying to measure the scale of your work. Better metrics would be what specifications you implemented, features you added, scalability (# of users or servers). You wrote 21k lines of code, but code wasn't your end result. That code did something beyond getting piped into wc, I hope. :)

</comment></comment></comment><comment><USER18> As a rule, if you're going to make someone feel ignorant, do so in a way that's relevant to the job. That rule would imply cutting the link to Chesterton (if they get the reference, they'll appreciate it) and possibly the Hofstader's Law reference, too.

In general, very nice. I used to be a recruiter, and I wish I'd gotten more résumés like this. (Keep in mind that the average recruiter, perhaps even at Google, will prefer a résumé that lists jobs, education _maybe_ skills, and nothing else. The filters in recruiting are designed to suppress originality, since there are far more original ways to make the wrong decision than to make the right one.)

<comment><USER19> _As a rule, if you're going to make someone feel ignorant, do so in a way that's relevant to the job._

Agreed, but...

 _That rule would imply cutting the link to Chesterton (if they get the reference, they'll appreciate it) and possibly the Hofstader's Law reference, too._

I wonder why do you assume people who know Chesterton would appreciate the reference. Just saying that you like Chesterton might suggest religious and philosophical beliefs that aren't necessarily appreciated by your average young liberal geek. I'm not saying people will dismiss OP right away just because of this, but unconscious discrimination does happen.

On the other hand, Hofstadter is both well known and generally liked among geeks.

</comment></comment><comment><USER20> Yeah. It's spelled "resumé" or "resume", not "résumé". (That would be pron "ray-zu-may" rather than "reh-zu-may".)

<comment><AUTHOR> Actually, all three are correct. From <http://en.wiktionary.org/wiki/r%C3%A9sum%C3%A9#Usage_notes> \-- "In the US, there are three major spellings of this word: résumé, resumé, and resume. All three are in common usage and all three are occasionally contested. The usual justification for each is usually as follows..."

Update: Being pragmatic, I should probably use "resume", because that's how Google Jobs spells it.

<comment><USER20> Hm, "protégé, émigré, née, and élan" all bother me, too. The diacritic means "pronounce this", imo, but English is as she is spoke.

Yeah, it's the web, it's probably safest to stick to ascii ;P

</comment></comment></comment><comment><USER21> Sorry to answer a question with a question, but what is it that you want to do for Google?

<comment><AUTHOR> Fair question. Develop web apps, really. But I'm pretty open, and plan to leave my "what I want to do for you" for the cover letter when applying for a specific job.

<comment><USER21> Cool. I can't speak for their current interview process, but I went through the phone screen mechanism a few years back. My problem was that I wasn't sufficiently focused in one area; I tried to market myself as both a Systems Engineer and a Software Developer (which is common for start-up-prone types such as myself). My biggest take-away from the interview process was that that was a bad idea. I suggest that you focus on a particular area; web apps alone is still possibly not specific enough. They'll perhaps want to know what specific technologies or facets of modern web apps you are into and proficient in.

Of course, that was then and this is now. Some other HNers probably have better advice:)

</comment></comment></comment><comment><USER22> It doesn't really sound like this is what you're looking for, but Google has a really nice branch in Sydney. Sadly, immigration issues kept me from joining them, but I think (?) that a New Zealander wouldn't have that problem.

</comment><comment><USER23> Not quite related, but I highly recommend reading <http://courses.csail.mit.edu/iap/interview/materials.php>

</comment><comment><USER24> Are you looking for jobs at startups, who want to build web-apps. We're a Ruby + Rails shop, but there are many python startups doing wonderful things in SF.</comment>


Why Android users surf less than iPhone users - <AUTHOR> http://www.quirksmode.org/blog/archives/2012/12/why_android_use.html <comment><USER2> iOS user here, so bias acknowledged, but I am a mobile security guy and I get new phones quite often.

Just last week I fired up the new Google Nexus device from LG and tried to spend a full week on it--for the purpose of being more familiar with Android as a user.

I couldn't make it a full 24 hours.

This was a fully stock Android experience, on the latest and greatest phone, and Chrome crashed six (6) times on me. Scrolling in the browser was markedly inferior. And the overall experience of reading on the device just felt far worse.

I didn't want to read anything on it, honestly. I tried to account for my own bias towards iPhone/iOS, but I don't think it makes up even half of the bad experience I had.

In short, I think Android phones discourage, from a UX standpoint, the activity of browsing. And I think that's a much larger factor than that mentioned in the original post.

<comment><USER3> The scrolling difference is due to differences in how Android and iOS prioritize things. On iOS, putting your finger on the screen stops _all_ processing on the page - no rendering, no animation, no Javascript, no downloading, nothing runs until you lift your finger off the screen. This lets the system devote 100% of its processing power to moving that rendered graphic around.

Android, by comparison, continues to perform its tasks while you scroll. This means that the scrolling can be jerkier if things are loading, but you continue to get a full interactive page while you're scrolling.

Speaking as a developer, iOS(/mobile Safari) gives me fits. It's the mobile generation's IE6.

<comment><USER2> Well, given that a tiny fraction of users are developers, doesn't it seem like a poor decision on Google's part to have a poor user experience in order to help in some other area?

Seems like UX should in fact be the highest priority.

<comment><USER3> The way that iOS does things prevents developers from doing things to help UX! For example, as an effect of this prioritization, iOS doesn't report scroll position while you're scrolling a page or scrollable div in a page, until the scroll has completed, and the scroll momentum has come to a full stop. This makes all sorts of app-like interactions impossible in an iOS webapp.

I don't really think that the user experience is poor, per se. I think it's a matter of acclimation; I've been using Android since the Nexus One, and while it was certainly frustrating in the past, Android 4.1 really stepped things up, and it's a really nice experience now. I appreciate how iOS scrolling feels, but in general, Android's way of doing things seems to be a lot nicer to me. I actively use Android and iOS devices on a daily basis (my phone is an LG Nexus 4, the same one you disliked), and Android feels much, much better to me than iOS does, with the sole exception of scrolling smoothness.

It's worth noting that there is one difference that might have been annoying you; iOS starts scrolling as soon as you start moving your finger. Android has a deadzone of a few pixels, so it might feel less responsive if you're used to the lack of deadzone on iOS. Once you're used to it, it's not an issue.

</comment></comment></comment></comment><comment><USER4> This is ridiculous, if I'm reading it right.

For one thing, the carrier I currently use (AT&T), forces you to buy a data plan if you have a smartphone. I'd be surprised if this wasn't the case for all carriers. So that blows the conclusion out of the water.

But why ask the question in the first place? Because the Android browser market share is so much lower than the Android market share as a whole? I would presume that "browser share" comes from the web, which can be accessed by all sorts of devices, and "mobile market share" comes just from mobile devices. That alone probably makes the question moot. But even if it didn't, there's Opera, Firefox, Chrome and all sorts of other browsers on Android that could make up the gap.

In other words, I doubt the premise (Android users surf the web less) as well as the conclusion (this is due to most Android users being too price averse to use data). I just don't see any evidence of either.

<comment><USER5> I have a data plan on an iPhone with AT&T and I pay an additional $15 over the standard 450 minute plan for 200 MB of data. I understand that AT&T has raised this minimum to $20 for 300 MB.

That price won't break the bank for most people but 200-300 MB for a month of data isn't much. I'm generally on WiFi so I don't care but I suspect that many people would find this too small for comfort. If they don't care about surfing from the phone, I can see people just avoiding using any data at all so that they don't have to worry about additional fees.

<comment><USER6> I'm with AT&T and went to the $15/month a couple years ago (don't know if the price went up, I'm on someone else's contract and I've never actually seen the bill). It's a pain to worry about bandwidth, and video is out of the question. Yes, WiFi bandwidth is free, but sometimes I forget to turn on WiFi, then almost have a heart attack when I see how much bandwidth I've consumed (thanks to the "3G Watchdog" app). It's just significantly less stressful to put the android phone down on my desk and just surf on my desktop or laptop on my Cable connection.

</comment></comment></comment><comment><USER7> The average Android user may surf less than the average iPhone user, but there are also way more of them. There are loads of cheap low-end Android devices that are able to browse the internet, but the people who buy them are not so interested in that. Apple doesn't make low-end phones (although they do sell old models), so it is a much more conscious decision to spend that much money on a phone. I think that if you take out all the people who went to a store "just to buy a phone" and just include people who buy high end models like the Samsung Galaxy, Google Nexus etc. the browser usage picture is not that different from iPhone users.

<comment><USER8> _There are loads of cheap low-end Android devices that are able to browse the internet, but the people who buy them are not so interested in that_

Case in point: my wife and I both have Android phones, so when my mother in law needed a phone, we got her an Android too. She has not used the internet once on it, but we installed a few apps to make it easier for her to use (e.g. one app puts a picture of the last person who called on the home screen). We also set it up to dial out through Google Voice (total integration is best on Android, including replacing the dialer). I bet a large portion of Android users fall into this category.

</comment></comment><comment><USER9> As an Android user, I would guess that the most significant reason why Android users browse less may have more to do with conserving the battery than anything else. My experience with Android and the battery life has been miserable. My Nexus 4 seems better, though.

</comment><comment><USER10> Wait, what? The whole premise is completely and utterly false?

[http://gs.statcounter.com/#mobile_os-ww- monthly-201112-20121...](http://gs.statcounter.com/#mobile_os-ww- monthly-201112-201212)

Android: 33% iOS: 23%

That is a major difference in favor of Android. Why write a blog post without even checking the data?!

<comment><USER11> iOS still has a clear lead in North America.

<comment><USER10> And Android has a clear lead in China, the biggest market. These stats also largely mirror the distribution of Android phone purchases. What's your point?

[http://gs.statcounter.com/#mobile_os-ww- monthly-201212-20130...](http://gs.statcounter.com/#mobile_os-ww- monthly-201212-201301-map)

Worldwide, Android still leads by 10% in web browsing.

<comment><USER12> As multiple people have pointed out, the reason Android "leads" by 10% in web browsing (especially in China) is because there are a ridiculous number of cheap Android phones out there, leading to a larger amount of _total_ traffic from Android.

To really understand what the OP is talking about, you need to think in terms of _per capita_ browsing in iOS and Android. In other words, how much web browsing does your average iOS user do, vs your average Android user? That is really what matters.

</comment></comment></comment></comment><comment><USER13> You failed to mention that the iOS Safari market share is the same as Android's, which makes sense considering they have about equal installed bases right now (although the Android one is growing much quicker).

</comment><comment><USER14> I'm not sure i agree with his reasons, mostly because what the data really shows is that Android users don't really browse on Wi-Fi [1] (on 3G the discrepancy - device marketshare vs browsing marketshare - is much lower).

My opinion (with anecdotal evidence) is that Android users just stick with their PCs when at home (presumably when they have Wi-Fi), whereas iOS users prefer the small screen, for some reason.

[1] [http://blog.cloudfour.com/explaining-the-ios-and-android- mob...](http://blog.cloudfour.com/explaining-the-ios-and-android-mobile- disparity/)

<comment><USER15> Seriously, they distinguish between mobile browser usage on Wi-Fi vs 3G? That doesn't make much sense, at least not if you wonder what device you should optimize for. Perhaps you could conclude that Wi-Fi surfers would tolerate bigger web sites, though.

</comment></comment><comment> jack-r-abbit Android user here. I don't do a lot of surfing on my phone because I would rather use a larger screen. Using my wife's iPad or my Asus tablet is a little better but I still prefer to use my laptop when it is handy. So if I am out and about and really need to access the web, I do it. But when my laptop is just in the office... I use the laptop.

I don't think the data is complete unless you also include whether or not these same people even have a computer anymore. Whether it is right or wrong, we keep being told that the desktop is dead... so maybe iOS users have bought into that idea more than Android users. If all you own is an iOS device.. you don't really have much choice of how you surf the web.

</comment><comment><USER16> Android is the default OS, so naturally it picks up a lot of users that don't want to use all of it's core features. No surprises here.

</comment><comment><USER13> Here's the report he's talking about:

[http://www.quirksmode.org/blog/archives/2012/12/browser_stat...](http://www.quirksmode.org/blog/archives/2012/12/browser_stats_f_5.html)

What does he find so strange about this? The chart counts all phone browser market shares. And Android's user base is not 5x that of iOS, if that's what he's implying.

His article makes no sense, because the data he's talking about doesn't match at all his "conclusions". The 48% number is for _smartphones only_ , meaning mostly just Android and iOS, as the others are very tiny market share. But it's not the whole phone market, as the first chart above shows. So he's mixing both, and concludes that "Android has half of the market, but only 24% browser share". Ugh, this post is a mess.

Android has half the SMARTPHONE market, but has much less from the PHONE market. That's why it only has 24%, just like iOS in the PHONE market.

<comment><USER10> Why use old data? Use current data and argue a position from there.

[http://gs.statcounter.com/#mobile_os-ww- monthly-201112-20121...](http://gs.statcounter.com/#mobile_os-ww- monthly-201112-201212)

The Q3 data point is just before iOS and Android began to diverge dramatically.

</comment></comment><comment><USER17> I would argue that Android users generally have more important/interesting things to do than surfing on their phone all day.

<comment><USER2> In case you're not trolling, why is it that the business class cabin of most flights is full of iPhone users? Why is it that most artists, journalists, photographers, etc. seem to lean heavily towards iOS?

I'm not saying you're wrong, I'm just asking what group you think it is that is highly busy/productive, on Android, and doesn't show up in web logs?</comment></comment>


From Harlem to Herrang: An Original Lindy Hopper Blooms in Sweden - <AUTHOR> https://www.nytimes.com/2018/08/10/arts/dance/lindy-hop-herrang-norma-miller.html <comment><USER2> I have many happy memories of weeks at Herrang. In fact I got offered my first job in open source there after a chance meeting, and my first startup can trace its origin to some conversations with other hackers in between dance classes.

</comment><comment><USER3> If you haven't seen the lindy hop scene from Hellzapoppin', you are in for an absolute treat. Norma Miller is the lady in the cook's outfit.

[https://www.youtube.com/watch?v=ahoJReiCaPk](https://www.youtube.com/watch?v=ahoJReiCaPk)</comment>


Crash Tags - <AUTHOR> http://www.holovaty.com/writing/crashtags/

<comment><USER2> A defiantly nerdy take on Twitter. I appreciate it for what it is, but I don't agree. Twitter and its constraints aren't silly.

An arbitrary and mostly-irrelevant technical limitation is responsible for the 140 character limit. But, it turns out that limit or no, 140 character messages have utility. Forced summarization means that you can benefit from updates from hundreds of people simultaneously.

Compare Twitter to the Facebook feed (I follow a comparable number of people on both). In neither case can I reasonably consume 100% of the stream. That's OK. But: I am objectively capable of benefiting from a far larger percentage of the Twitter stream than I am of the Facebook stream. I go two or three pages down Facebook and I'm saturated. I could never in a million years pay attention to it all day; I dip into it maybe 2-3 times a week.

The fact that Twitter sort-of works for this broadcast-y use case means that is sane to build things on it, like news services, or conference CFPs, or recruitments for open-enrollment classes, or announcements for new blog posts.

There are clearly things Twitter has wrong, and hashtags and inband metadata are clearly at the top of the list. But that doesn't make Twitter silly. The Twitter team apparently didn't know Twitter was going to work this well when they started it. It isn't some crazy scheme to trick the linkerati. They're still catching up to what they unleashed and I'm inclined to cut them some slack.

<comment><USER3> The thing is, I don't see any effort by Twitter to try to separate the inband metadata, except for what they did with in_reply_to (which continues to have problems). They should have done exactly the same for hashtags, URLs, and pictures a long time ago. As a result, URL shorteners have spread across the web like a disease and tweets are #goddamn #liketotally #nearunreadable <http://bit.ly/mjSZ1G> now, unless you have a client that gets rid of the junk for you. I don't see the top-down, platform-level vision from Twitter about how they'll _innovate_ and make the UX better, instead I just see them sucking up all the startups that built products around their service.

You can make a better UX for a broadcasting service than by having people squeeze more characters in by switching to a tinier URL shortener and using sillier hashtags. I'm hoping to see some movement that actually indicates they know what a problem this is.

<comment><USER2> Let's all agree to agree:

* URLs shouldn't count towards the 140 character limit.

* Tags should be out-of-band

Having said that, I read and write twerps every day. Most of the people I follow use hashtags only in an ironic sense, and I never pay attention to them. I agree that they are poorly engineered for their problem domain (but again: I cut Twitter a lot of slack on this), but I am not kidding: Twitter is more useful than Facebook, with its rich out-of-band metadata and commenting features, on a daily basis, to my business. I would be unhappy if Facebook- style messaging replaced Twitter.

</comment></comment></comment><comment><USER4> In the comments of one of the links there, someone suggests adding Circles to the post, even if it's already public, as a way to simulate hashtags.

I like that, but the problem is that nobody else can see what circles you published to. (Which is probably how it should be, so they can't figure out how you've organized people. It's a privacy concern.)

<comment><USER5> "This stomach flu sure sucks, you guys [shared with #work]"

"Awesome kegger last night, breauxs! Can't believe I did twenty shots! [shared with #alphabetagamma]"

</comment></comment><comment><USER6> #constraints #value #cognition #paradoxofchoice

</comment><comment><USER7> I look forward to seeing how G+ solves this, it's my core issue right now that I'm getting barraged with photos from people I don't know well. I'm not really into seeing random photos of food, whatever, but I like what they have to say when they actually post text. I also see G+ being like Twitter in that you can engage with the community on core topics rather than having to know who to follow. I'm sure I'm missing out right now on great conversations because I don't know who's posting them.

I'd also like to be able to use G+ as my blog on certain topics that some friends care about, but not enough for me to reach out to them and ask if they'd like to be in my 'postings about this topic' circle.

</comment><comment><USER8> The 140 character limit is actually a nice feature. It's like reading a stream of headlines rather than parsing articles and animated gifs. G+'s circles are kind of a pain to manage and post to. In addition, they ruin the serendipity that you find in your twitter stream. For example, discovering that a programmer acquaintance also enjoys running or one of your favorite bands.

I'm not saying that G+ is going to fail, but it doesn't make twitter archaic or obsolete.

</comment><comment><USER9> The title made me think of HTML tags.

</comment><comment><USER10> 140 is a feature, not a bug. But anyway, hashtags have nothing to do with the character limit, and everything to do with search and conversation. They make it easy to find people all talking about the same subject, with no group setup or other configuration beforehand.

I know a lot of nerds hate Twitter because they think it's "for the cool kids" or whatever, but this is silly.</comment>