jbrowning

# The $provide service is used to override an injected dependency

# Bad - results in Error: [ng:areq] Argument 'fn' is not a function, got Object
module 'someModule', ($provide) ->
  $provide.value "SomeService", SomeMock

# Good
module 'someModule', ($provide) ->
  $provide.value "SomeService", SomeMock
  null

j883376

#!/bin/sh

# in case it's already installled
vagrant plugin uninstall vagrant-libvirt

# vagrant's copy of curl prevents the proper installation of ruby-libvirt
sudo mv /opt/vagrant/embedded/lib/libcurl.so{,.backup}
sudo mv /opt/vagrant/embedded/lib/libcurl.so.4{,.backup}
sudo mv /opt/vagrant/embedded/lib/libcurl.so.4.4.0{,.backup}
sudo mv /opt/vagrant/embedded/lib/pkgconfig/libcurl.pc{,.backup}

jonathan-kosgei

I have been an aggressive Kubernetes evangelist over the last few years. It has been the hammer with which I have approached almost all my deployments, and the one tool I have mentioned (shoved down clients throats) in almost all my foremost communications with clients, and it was my go to choice when I was mocking my first startup (saharacluster.com).

A few weeks ago Docker 1.13 was released and I was tasked with replicating a client's Kubernetes deployment on Swarm, more specifically testing running compose on Swarm.

And it was a dream!

All our apps were already dockerised and all I had to do was make a few modificatons to an existing compose file that I had used for testing before prior said deployment on Kubernetes.

And, with the ease with which I was able to expose our endpoints, manage volumes, handle networking, deploy and tear down the setup. I in all honesty see no reason to not use Swarm. No mission-critical feature, or incredibly convenient really nice to have feature in Kubernetes that I'm go