As part of cleaning up your local Docker environment you can remove all your images.
The following alias will do that quite nicely:
alias docker-prune='docker rmi $(docker images -q)'
Have you ever tried to use git rebase and noticed that it does NOT work on the first commit in a branch?
Is there are way for a rebase to include the first commit?
There actually is! Use the following command line:
git rebase -i --root
This will trigger an interactive rebase that will include the first commit. Perform the rebase as you normally do.
Note that if you decide to push this back to a remote Git repository be aware you are rewriting your Git history so it will break folks that already have the Git repository pulled down.
When running Docker you pull down images. Those images can take up quite a bit of space. After tagging / retagging / untagging you can end up with dangling containers. So a bit of house keeping needs to be done.
The following command line will get rid of the so-called dangling containers:
docker mi $(docker images -q -f "dangling=true")
For bash users the following alias will come in handy
alias docker-scrub='docker mi $(docker images -q -f "dangling=true")'
Using the 2 previous blog entries this becomes trivial if you use bash:
alias docker-down='docker-kill ; docker-rm'
After you have killed all you containers you might wonder how you would go about removing all those killed containers.
Well it is really very easy and similar to killing all the containers.
docker rm $(docker ps -q -a)
And for bash users the alias would be
alias docker-rm='docker rm $(docker ps -q -a)'
When developing with Docker you'll probably find a need to kill all your docker containers at once. While you certainly can kill them one by one the following commandline takes care of it in a one-liner
docker kill $(docker ps -q)
If you use a bash shell I would recommend you create an alias for it so you can issue the commandline in one go
alias docker-kill='docker kill $(docker ps -q)'
I have been thinking a lot lately about how we approach software.
OK let me ask you a REALLY important question. When you are writing software that fulfills a business need do you think about how long your software is going to be around?
If you answer NO then you are doing yourself a disservice. While you can be solving the business in the short term you SHOULD also think about the long term.
Or maybe I should ask the business owner the following question? How long are the developers you asked to fulfill your business need going to be around? In our industry you have turnover and as business owner you need to make sure that you set yourself up for SUCCESS which means making sure the software that is chosen to fullfill your business need is used by more than just your current developers.
What do you think are other things we need to keep in mind when writing software?
I would love to hear from you!
Java.net is going dark!
And it is the end of another era, Java.net is going dark, read about it at https://community.oracle.com/community/java/javanet-forge-sunset
Just like the previous blog entry I have a wish for JAX-RS which would intersect with the CDI specification. I wish that @Inject would work on JAX-RS methods.
What do you think?
While working with CDI I have always wondered why the CDI JSR does not take over the responsibility of JSR 330 by merging it into the CDI specification.
Do you think the CDI JSR should merge JSR 330 into the CDI specification?
Leave your comments!