bsnape

A great release with lots of important bug fixes that were giving us issues.

We like to use hosted services rather than host them on-prem where possible (AWS, Artifactory, Slack, GitHub).

For the size of our company we have relatively few engineers. Not hosting things ourselves increases our productivity and we can concentrate on our own products :-)

Sorry, yes, will change in 12 months time. I'm sure they will force the new pricing structure then (and that's cool).

Billing screenshot: http://i.imgur.com/k1F0BxA.png

Haha we probably spend a lot on toilet paper as we have ~5k employees (FTSE 100 company) but that isn't the point I was trying to make :-) it doesn't matter how big or rich you are - if costs for a thing increase by x3.5 it's probably going to have an impact. I'm no enterprise-lover and we spend tons of money on crap with annoys me but I'm not in a position to change that.

We are not a "technology company" (and unfortunately I'm not the CTO!) so we will have to report upwards that costs will be increasing x3.5. Their reaction will probably be to ask us to investigate alternatives.

It looks like smaller companies/startups will benefit much more from this change which is fair enough to charge the big boys more really.

I'm not asking anyone to get their violins out but it makes me a little sad that we may have to move away from GitHub. On the flip side, GitLab has been looking great lately!

This has almost quadrupled our monthly cost ($850 vs $2914). We have ~300 users which will have to be reduced massively to save costs - perhaps with non-engineers sharing accounts or having no access at all. I'm not sure if charging per user is really in the spirit of open collaboration that GitHub champions.

I slo wonder if charging per user rather than per repo will also discourage the creation of open-source repos from orgs? There's no longer a (reduced) cost benefit after all, even if that was a minor influence compared with the other benefits of open-sourcing your code.

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

http://www.amazon.com/The-Phoenix-Project-Helping-Business-e...

How many humans kill other humans with only their bare hands? Humans themselves are not dangerous, and weapons are not animals.

If DHH's main concern was practicality he wouldn't advocate UI & DB tests which are flaky, unreliable and expensive to maintain for any non-trivial application.

Code and system architecture absolutely should be bent to the needs of testing. Pretty and "clever" code is useless unless it does what it's supposed to do.

UI & DB tests absolutely have their place - I'm not disputing that at all, and I completely and whole-heartedly advocate their use - but they need to be used in conjunction with very fast, very reliable (and thus very useful) unit/integration tests that have been TDD'd.

I think you're perhaps missing the point in one or two places.

Cucumber helps techies (devs, testers, etc.) and non-techies (product owners, scrum masters etc.) work collaboratively. I don't think the authors of Cucumber ever said that it enables non-technical people to 'read and understand the underlying code'.

Ultimately though, I agree with your conclusion but for slightly different reasons. I use both RSpec and Cucumber daily; they are both awesome and provide a similar end result. I enjoy writing Cucumber features but in certain circumstances it doesn't scale for large/complex applications (in my experience). I think that this isn't a problem for many people though, unless they're doing something wrong 'under the hood'.

This looks fun: http://cryptogasm.com/webcams/webcam.php?id=35941

Baseball: http://cryptogasm.com/webcams/webcam.php?id=35918

Some sort of dog kennel: http://cryptogasm.com/webcams/webcam.php?id=36541

Kid and dad playing video games: http://cryptogasm.com/webcams/webcam.php?id=35548

Cockroach cam: http://cryptogasm.com/webcams/webcam.php?id=24313