Hacker Newsnew | comments | show | ask | jobs | submit | login

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.

-----


>> staging servers so non-technical staff can check the work of "their" developers

Surely staging servers have some other benefits? Maybe some teams consider running code on the production setup for the first time to be risky to their customers? Perhaps some teams have encountered differences between dev laptops and production servers, which run on different OS/memory/etc. combinations?

-----


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'm a dev at a company and I pushed for us to have a staging environment _and_ QA. When I started at my current job, it was common practice to edit code in production, and there was no testing (automated, QA, anything).

In our case, having a staging server (which is really a prod server since it's used for some internal stuff) gives us a chance to check a few things:

1. The installer still installs everything properly. 2. The main website works 3. Web services work

We don't have any hard and fast rules about how long things sit on staging, but having a staging system is useful.

So there you have it, a staging environment driven by engineering.

-----


Staging servers are not only a great idea, they are a life saver (read: job saver/career saver) when you are running large, mission critical apps.

I push things right into production when I'm playing with a new site. I use a staging server when I'm working on something serious.

-----


You honestly can't think of good engineering reasons not to push new code directly into production?

-----


too busy crushing it to use a staging server

sorry you aren't a technical coder

you probably even file bugs instead of just monkey-patching it in production like a real man

(srcub)

-----


You might want to do fewer, less frequent releases in order to provide training to end users. You might also want to do do fewer, less frequent releases in order to facilitate a marketing push centered around the release.

-----


well I heard New Relic today saying they run their own production monitoring on their staging.dogfood it first...

-----


What really sets GitHub and to a lesser extent 37signals apart is that they are making a product for themselves. That's how they manage to only hire doers. They don't need marketing or usability testing or operations or acquisitions beyond what the doers provide because the feedback loop to the target market is near direct. That's not to say it's easy to do what they've done, but rather it's much less likely those principles could be held as the staple of companies in other markets where engineers and designers will not be as naturally adept at nailing product/market fit by themselves.

-----


> 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

Then you can imagine how many people outside of the Bay area do the same thing. I've worked at places where I (stupidly) suggested some of their principles as solutions to systemic problems that came up, assuming that everyone would be on the same page (I mean their ideas just make sense right?) ... no way. I've gotten laughed out of the room a couple of times, wised up and am now resigned to the fact that unless I start my own company or join the founding core of a startup, I'll never get to apply those kinds of ideas unless I work in the Bay

-----


Don't give up so quickly. Sneaking in good ideas into companies is a skill that takes time to learn, and even when mastered takes patiences to exercise.

-----


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.

-----


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

-----


Sonic boom followed in 2 minutes, so the altitude was in 30-40km range. That's damn impressive, with all the sharp shadows from the buildings ... damn.

-----


Why do you suppose there would be two contrails?

-----


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."

-----


I wouldn't think they are contrails. One would expect them to mainly be smoke and dust from the disintegration/combustion/ablation during the descent.

-----


By definition, they aren't "contrails". A "condensation trail" can only happen when something like an internal combustion engine injects water (or another compound that will condense) into the air.

-----


A fast object compress the air in front of it reducing the amount of water that can be solved into it, so the excess of water condenses.

It's very visible in planes about to break the sound barrier. Look for Youtube videos. The cones are spectacular, but also notice how a trail is sometimes visible originating from the tips of the wings.

So you don't need to inject the water, but to extract it from the air compressing it. Anyway, I'd bet the meteor trails consist of vaporized matter from the meteor itself.

Edit: see this one at 0:20:

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

-----


It's true you can get water condensation features from local pressure minima like in wingtip vortices. However, they are transient, because as soon as the air returns to ambient pressure the condensation goes away.

-----


Well. If the meteorite was partially composed of water, which was then vaporised off during the atmospheric ablation, then it might indeed be partially contrail!

A pure water meteorite hitting the atmosphere would be contrails all the way; just not in the way we're used to.

-----


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.

-----


Is there a reason for using both HAproxy and Nginx?

-----


HAproxy is a more efficient load balancer for really high scale apps. That said, only about 5% of people would see a difference in load/memory usage. Source: I work for EY.

-----


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.

-----


By breathing technique I am referring to something slightly different than watching and counting breaths, which in itself is somewhat austere and easy for the mind to wander. You also are inherently relying on the mind to keep track of things. How to achieve no-mind using the mind? This is tricky.

I was referring more along the lines of pranayamas, mantras and other techniques that drive the mind into submission. The mind will be completely stunned after 10-20 mins. Look into any tradition be it buddhist, yoga, tantra etc and you find some other options.

-----


There's something strange going on around breathing. By combining it with body postures, or focusing on certain parts of the body, or repeating (mentally or out loud) certain sounds, or just breathing in a certain way, all sorts of strange unexpected things happen, either purely at the consciousness level or even physical sometimes.

These techniques must put pressure on some deep, otherwise unconscious levels of the mind, and then produce responses closer to the "hardware" level. I'd love to see more research done in this area.

(Note: I don't practice Vipassana, but different, yet overall somewhat similar, techniques of a school of yoga - and I mean yoga in the traditional sense, not the bastardized "female yuppie gymnastics".)

-----


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.

-----

More

Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: