carbon8

Short-lived staging environments (eg, a temporary clone of a production environment) certainly have a place, such as when making architectural changes, but these kinds of changes are generally not happening on a regular basis if you are making incremental changes and doing continuous deployment.

I'm sure that there are companies that have a valid engineering need for perpetual staging environments rather than feature flags, but I've seen absolutely no evidence that staging servers are commonly engineering driven. Certainly in every part of the web startup world I've had contact with or heard about, staging environments have consistently been for product QA in organizations with heavy-handed processes and/or product management by non-technical stakeholders.

Edit for the people responding: This is not about haphazardly pushing to production. You should familiarize yourselves with continuous integration (http://en.wikipedia.org/wiki/Continuous_integration) and the various deployment strategies of major web companies.

I've found it interesting how many people in the Bay Area, particularly veterans of the 90s boom, discount a lot of the ideas pushed by GitHub and 37signals. Anedotally, one of the common responses whenever I reference either company is, "Yeah, but how big is [GitHub|37signals], really?" It's actually somewhat surprising to me how consistently I've encountered this response (so consistent, it feels as if it was distributed like a political talking point). As mentioned in the slides, publicly announced funding definitely serves as a signal, and I haven't heard anyone say that about GitHub since then, though someone said it to me regarding 37signals within the past few months.

What I think it really has to do with is that GitHub seems to make an effort to hire doers, whereas many companies develop processes to deal with non-doers, eg, having staging servers so non-technical staff can check the work of "their" developers. Remote work also doesn't serve the interests of non-doers, since they want to Have Meetings and Make Decisions.

Also, from a Kauffman Foundation report:

"The average and median age of U.S.-born tech founders [of companies that have more than $1 million in sales, twenty or more employees, and company branches with fifty or more employees] was thirty-nine when they started their companies. Twice as many were older than fifty as were younger than twenty-five."

http://www.kauffman.org/what-we-do/research/2009/04/educatio...

"The average and median age of U.S.-born tech founders [of companies that have more than $1 million in sales, twenty or more employees, and company branches with fifty or more employees] was thirty-nine when they started their companies. Twice as many were older than fifty as were younger than twenty-five."

http://www.kauffman.org/research-and-policy/education-and-te...

FWIW, having read through this book, I highly recommend it for anyone interested in learning Go. It provides a good, clear introduction to the language and is very easy to digest.

Parts of this post are premised the "influencer" marketing model, but there is at least some research indicating that it might not be as powerful as generally assumed. For example:

* http://misc.si.umich.edu/media/papers/wsdm333w-bakshy.pdf

* http://www.digitaltonto.com/wp-content/uploads/WattsandDoddi...

"Grouped: How small groups of friends are the key to influence on the social web," the book by Paul Adams @ Facebook (http://www.amazon.com/Grouped-groups-friends-influence-socia...), talks a bit about this.

Anecdotally, I've also seen quite a bit of evidence first hand that suggests the impact of influencers is not clear-cut.

Quoting Phil Plait's very early speculation (http://www.slate.com/blogs/bad_astronomy/2013/02/15/breaking...):

"It appears to split, so I’m guessing the main mass split there. That’s not surprising; it’s happened with previous falls (like Sikhote-Alin). That means they could have disintegrated at different times, so there may be multiple places where pieces could fall."

Two more good videos (high quality, trail/train detail, booms, etc):

http://www.youtube.com/watch?v=XDqYclzto7k

http://www.youtube.com/watch?v=0ozSq3yEm3g

Engine Yard is more like opinionated configuration management. It allocates and configures EC2 instances that you can log into like normal. The software stack is HAProxy, nginx, unicorn, etc, and customizable through the web interface and/or chef.

This sounds very similar to what I've heard from people who have actually worked with Jobs, as well as the Steve Jobs described by Ken Segall in Insanely Simple http://www.amazon.com/Insanely-Simple-Obsession-Drives-Succe...

Segall’s description of Jobs includes an important additional component: obsession with keeping things simple (hence the book title). Segall provides numerous anecdotes of Jobs beating an idea with the “Simple Stick,” as he calls it, and compares it favorably against his relatively frustrating experiences working with other companies like Intel and Dell.

Regarding #3, when practicing Vipassana as taught by Goenka, you do indeed start with anapana, both in the courses (the first 3 1/2 days are only focusing on breath) and in daily practice.

Agreed that it takes determination to continue, but I've managed to do the 1 hour morning and evening sittings for stretches, including a year or so while working full time and going to school. It's just a matter of incorporating it into a routine. Also, in my experience, since it helps maintain productive use of time, it's a net gain.

IMO, JSTOR isn't directly to blame. They are operating within a broken system, and it seems like they are doing what they can.

Academic publishing is what needs a serious overhaul.

After having worked in an academic library and, more recently, leading technology operations for a prominent new ebook publisher and article archive, the first two words that come to mind when I think of both publishing (academic and trade) and librarianship are "waste" and "bureaucracy."

Librarians are supposed to be the ones advocating for the readers, but they are hobbled by a culture of committees, conferences, and politics. They work within organizations that are heavily stratified ("librarians" and "staff"), with all the worst aspects of severely hierarchical organizations.

Recently I was also was privy to a variety of details during the formation of a new academic digital publisher, and it was the same kind of top-heavy, anti-"lean" structure you'd expect. The amount they were raising just to get started seemed absurd, especially when we were in the process of building a larger organization that did more with less funding.

The point being, when you look under the surface, it's no wonder that everything in this space seems to cost more than necessary.

There must be enough of us fed up, skilled, and idealistic enough to disrupt this space, creating new, actually modern publishers and/or publishing platforms if necessary.

Does anyone with more domain expertise have any advice about where to start or what to focus on?

Regarding what any of this means for other content paywalls, note this section from Post Industrial Journalism: Adapting to the Present (http://towcenter.org/research/post-industrial-journalism/):

"Finally, a note about why we will not be concentrating very much on the fate of the New York Times. A remarkable amount of what has been written about the fortunes of American journalism over the past decade has centered on the question of what will happen to the Times. We believe this focus has been distracting.

"In the last generation, the Times has gone from being a great daily paper, in competition with several other such papers, to being a cultural institution of unique and global importance, even as those papers—the Washington Post, Chicago Tribune, Los Angeles Times, Miami Herald, among others—have shrunk their coverage and their ambitions. This puts the Times in a category of one. Any sentence that begins “Let’s take the New York Times as an example ...” is thus liable to explain or describe little about the rest of the landscape.

"The Times newsroom is a source of much interesting experimentation—data visualizations, novel partnerships, integration of blogs—and we have talked to many of our friends and colleagues there in an effort to learn from their experiences and make recommendations for other news organizations. However, because the Times is in a category of one, the choices its management can make, and the outcomes of those choices, are not illustrative or predictive for most other news organizations, large or small, old or new. We will therefore spend comparatively little time discussing its fate. While the Times serves as an inspiration for news organizations everywhere, it is less useful as a model or bellwether for other institutions."

"the problem is that most people don't like browsing the internet on a phone or even a tablet"

The analytics on every site I've had access to in the past couple years suggest otherwise. iPad web traffic has been steadily rising and accounts for a significant portion of traffic on some sites. I've seen as high as 30+% on sites that haven't even been optimized for tablets yet.

San Francisco, CA.

Byliner Inc. is a publishing company and social network built around great stories. We are an online archive of long form journalism and fiction, as well as a publisher of original stories for iPad, Kindle, and other mobile devices.

We use Ruby, MySQL, Redis, Sass and are making the shift to using Backbone and CoffeeScript on the front-end. We also produce ebooks.

Looking for both UI and back-end developers. Full Time and/or contract.

Also starting to look for a designer for help with static HTML/CSS and graphics on a contract basis.

More info: http://byliner.com/jobs

The "check" icon next to the name on the profile page: http://i.imgur.com/Jzg8Y.png

San Francisco, CA.

Byliner Inc. is a publishing company and social network built around great stories. We are an online archive of long form journalism and fiction, as well as a publisher of original stories for iPad, Kindle, and other mobile devices.

We use Ruby, MySQL, Redis, Sass and are making the shift to using Backbone and CoffeeScript on the front-end. We also produce ebooks.

Looking for both UI and back-end developers. Full Time and/or contract.

Also starting to look for a designer for help with static HTML/CSS and graphics on a contract basis.

More info: http://byliner.com/jobs

http://www.w3.org/TR/css3-syntax/#at-rules

As I understand it, at-rules are basically directives to the CSS parser and, according to the spec, should be ignored if the parser does not recognize the identifier. Given that, the use of at-rules for variable names has always seemed, IMVHO, to break the purpose of at-rules.

Feedback noted. The reason some characters are missing is because I haven't had time to update it to include the new Unicode 6 characters. I'll do it ASAP.

Thanks for the HN love. This is actually one of my side projects. I'm a character and type geek and use this as a place to experiment and play with the data. Really glad to see other people find it interesting.

Let me know about anything that would make it more useful. I've kept it pretty minimal so it's easy to change things.

There are lots of little features that aren't immediately obvious, like user profiles: http://graphemica.com/people/alphabetum Also, cool stuff on the cjk characters, including definitions: http://graphemica.com/戰

San Francisco, CA.

Byliner Inc. is a publishing company and social network built around great stories. We are an online archive of long form journalism and fiction, as well as a publisher of original stories for iPad, Kindle, and other mobile devices.

We use Ruby, MySQL, Redis, Sass and are making the shift to using Backbone and CoffeeScript on the front-end. We also produce ebooks.

Looking for both UI and back-end developers. Full Time and/or contract.

Also starting to look for a designer for help with landing pages and graphics on a contract basis.

More info: http://byliner.com/jobs

"Read the iPhone app reviews..."

I went ahead and looked, and none of the complaints appeared obviously due to anything related to the current discussion.

The vast majority of them complain about "crashes" and problems logging in. The few complaints about it being "slow" appeared to be due to network issues, specifically related to getting new content from facebook. A handful report that content was attributed to the wrong user. Most of the remainder were just unsubstantial complaints. In the cases are something is actually mentioned, they are mostly about the lack of random features.

I've gone through many pages of comments on the app store reviews and I see no complaints that can be obviously attributed to the technology decisions discussed in the article.

In addition to what others have said, don't forget that ActiveX also played a strong role. ActiveX was pretty widely used in business-oriented web applications, which hindered business adoption of firefox even among those companies or individuals who wanted to move to it.

There was also a general distrust of open source software during the time that firefox was gaining adoption. With so much malware being spread via the browser (IE6), there was a fear that firefox's open source development model and perceived immaturity were a security and support risk.

Regarding sharing, on the mobile (or, at least, iPad) interface, the only sharing option I can see is the basic +1, which, as far as I can tell, isn't seen by anyone unless the go to a user's google plus profile and click the tab. As a result, I can longer share in any meaningful way via my primary consumption device.

Edit: to add, there doesn't appear to be any way to view my +1 items on my iPad, since the google plus mobile interface apparently lacks that section.

Also http://byliner.com/, focused on narrative long form non-fiction.

Perhaps you've had different experiences, but the issues raised in the book are things I've encountered repeatedly in new companies, and I've repeatedly seen new companies fail for exactly the reasons the book describes.

For many of us on HN there is little new information in the book. However, we have to recognize that the concept of experimenting with an MVP is completely foreign to many entrepreneurs, and even among those who know about and pay lip service to it, they very frequently can't commit to it in practice. I've seen this issue come up time and time with both new and seasoned, successful entrepreneurs. They think they know what customers want and cling to unproven notions irrationally. They get hyper focused on unnecessary features. They delay launches over fear of launching with an "imperfect" product, and also don't recognize that their vision of perfection is unproven and frequently flawed.

In fact, as a developer, this issues have come up in every project in which I've paired with a less-than-technical stakeholder. As someone who has been very active in startup communities, my observation has been that the tendencies the book intends to fight are rampant among non-technical founders.

I'm happy this book exists, because it's finally an easily digestible introduction to some baseline concepts that many entrepreneurs have a difficult time understanding and putting into practice.

What's with the use of curly brackets for multi-line blocks?

"Working Draft. Microsoft has committed to supporting standards, as soon as they are standards."

As you can see in the example pixelcloud cites, Microsoft does in fact implement features based on working drafts. They are already doing this with CSS3 transforms and will be doing so with CSS3 gradients, animations, transitions and flexbox. Therefore, that doesn't actually appear to be the issue at all.

"It's certainly arguable whether it's a good idea to implement draft standards that people write HTML for that then change under them."

Well, we are discussing CSS here, and that's what vendor prefixes (which Microsoft uses, too) help avoid.

"So they codified something that Mozilla and Apple were already doing,"

This is basically how the CSS3 standard progresses. Browser vendors implement a vendor-prefixed feature, and that feature works its way through the standards process. In fact, Microsoft does the same: http://caniuse.com/css-grid

Personally, I use RSS in Google Reader as a living bookmark system. I have about 500 subscriptions and don't pay any attention to the unread count. A couple times a week when I'm in the mood to check out stuff in a certain subject area, I'll go on google reader and click through things in that folder. For instance, if I'm looking for inspiration, I'll click through my "art and design" folder that has 50 to 100 feeds in it. Other times some business event will be in the news, and I'll go into my folder of business feeds.

Apparently using RSS in this way is somehow different than how most people use it. People complain about feeling guilty or somehow stressed out by unread counts. People complain about a psychological pressure to keep up with and read everything in a feed or collection of feeds.

However, I'm left wondering whether this is an issue with how the tools are designed, or perhaps with how RSS is framed. Perhaps we need to develop tools that deemphasize unread counts and instead further emphasize browsing or discontinuous digestion of the content streams.