21–30 of 139 posts
I love almost eveything GitHub does, and the way they do them. I'm a GitHub fanboy. There it is. I had a similar crush on Google, maybe 6-7 years ago, they lost me somewhere on the road.
I think they lost a lot of us as soon as the G+ train started rolling.
So.. the topic is wrong?
Seems like 20% of that slide deck is about chat rooms... GitHub still uses Campfire for chat? I tried Campfire and Hipchat a couple years ago, neither stuck. Not sure why, maybe poor offline notifications and logging? Or maybe our team didn't have enough timezone overlap or things to chat about? Hard to say. Is strong chat as important to Github as Zach implies?
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 distr…
>> 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?
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.
Please remove "[video]" from the title. As of right now there's no video (there's a placeholder saying it's coming soon.)
Earlier quoted context omitted.
I think they lost a lot of us as soon as the G+ train started rolling.
Speaking of the Google analogy, I hope they do more with their acquisitions of Speaker Deck and gaug.es, as I can't recall a single feature being added or improved since their acquisitions.
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 distr…
>> 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?
Dear github, please sort out your: - Intermittent angry unicorns - Slow data transfer (150kb/sec?!) - Poor support - Expensive enterprise licence, why don't you host a better service and i will pay for it?
If you are so fed up with them, why not host an internal Git service with gitolite for user access rules [1]. You could even add something like gitweb as a web interface for git/gitolite [2]. Or, better yet, use something like GitLab [3]. [1] http://sysadmincasts.com/episodes/11-internal-git-server-wit... [2] https://git.wiki.kernel.org/index.php/Gitweb [3] http://gitlab.org/
Earlier quoted context omitted.
>> 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…