I love working remotely for all the usual reasons, plus this more recent one: my 2yo daughter had ever-more-terrible eczema which we eventually learned was caused by molds ubiquitous to the region in which we lived. So we moved. Across the country. The very next day. She's light years better, and the whole family is so much happier. No job hunt, no asking for a transfer; we just moved.
Holy crap. Looked at the site and thought, "hey, pretty cool. I don't know what I would use it for, though."
And then I watched the video and have been coming up with use cases non-stop. Starting with adding vim key-bindings I'm trying to learn to iTerm. Bye-bye yellow-stickies all over my monitor!
Question, though. What if your notes are too context specific. So, for example, the note would bind to the specific file you are viewing in vim, whereas the contents of the note would be helpful for any file opened in vim?
One solution would be to have a hierarchy of contexts displayed in the note app. (Like breadcrumbs in file explorer). User could switch between context levels manually.
I thought it should be integrated in the OS, applications would set the context through the API. Software like this reads the context and manages the notes. That's to say I had a good impression, and I hope to see it on Windows one of these days.
Sorry to be slightly off topic but we could imagine the browser adapting to the context, too. There'd be a dropdown menu to select for example "Photoshop context", then it changes tabs according to the open project, and remembers them between sessions.
Docker also enforces immutability. With a VM there's always the temptation to manually fix any issue that arises, and if you don't have some bulletproof way to document that then you'll have issues when you go to recreate the environment on a new machine. Docker kind of forces you to solve the original problem via the dockerfile, which is what will spawn images for any future installs anyway.
Could you explain this more? I think my confusions stems from where the config comes from. Regardless of whether I have a bit-for-bit image or a vm created from a bunch of script commands, the immutability disappears when I apply the config.
So for my example If I have a role that specifies one instance of a a galera server. I have to config each one with the other servers in the pool. And each config will be dependent on the other server's config. So is Docker the first part (get the galera server instance running) and then there is some 2nd part that does the config so the instances in the cluster work together?
To your first question: for me it's a on-paper vs reality difference. On paper you're exactly right re "vm created from a bunch of script commands" will end in the same state.
The reality is that once the VM is built there is the temptation/opportunity to make ad-hoc changes for any variety of reasons. Those ad-hoc changes sometimes make it back into the official build process, but sometimes they get forgotten in the heat of the moment. With docker you can't do this...to make the necessary change you are also changing the official build process. No opportunity for the two to deviate.
Second question: Yes, that is my understanding (though not a use case I have atm).
Very good call out. For most use cases this actually turns out to be OK, but to reduce the surface area of this being a potential issue you could:
- Vendor dependencies (works to replace stuff like `go get` but probably not for apt packages etc.)
- Create a base image which handles the stuff you need to reach out to the network for (`apt-get install openjdk-6-jre` etc.) and is infrequently updated. Then the Dockerfile for the final application is `FROM me/myjava` and just does a few things that don't use the network like `ADD . /code`.
- Use `docker commit` instead of Dockerfiles for those steps (pretty gross IMO)
- Use CM in your docker build to install a very specific version of a package if you need (I'm not 100% sure this exists but it seems probable). This isn't perfect but tightens things up if you're worried about upstream breaking apt packages etc.
One of the goals of a new image format for Docker (this is 2.0 stuff) is to make the layers content-addressable by ID. That way, you will have a reasonable assurance that two Docker images constructed with the same Dockerfile in two different places will have the same IDs if they result in the exact same layers, and you will be able to see the point of divergence otherwise.
"- Create a base image which handles the stuff you need to reach out to the network for (`apt-get install openjdk-6-jre` etc.) and is infrequently updated. Then the Dockerfile for the final application is `FROM me/myjava` and just does a few things that don't use the network like `ADD . /code`.
- Use `docker commit` instead of Dockerfiles for those steps (pretty gross IMO)
- Use CM in your docker build to install a very specific version of a package if you need (I'm not 100% sure this exists but it seems probable). This isn't perfect but tightens things up if you're worried about upstream breaking apt packages etc."
These are some of the goals of ShutIt.
We had complex development needs due to technical debt, and dockerfiles simply didn't cut it, and I got frustrated with the indirection of chef/puppet/ansible. I also needed the several hundred devs in my company to get productive quickly, so transferring all the little bash scripts and storing it in docker was the path of least resistance.
It's out of date and heavily edited, but I talk about this here:
ssllabs took > 5 mins for a couple of sites i tried, while OP's was pretty instantaneous. It gave more detail, to be fair, but in terms of trying to catalyze a decision from a non-technical decision-maker, or for a quick sanity-check, I think I'd reach for expeditedssl.com first.
"And people like me, who pretend to themselves that they have a reasoned investment thesis, will say fuck it, and cash out in hordes."
That's a pretty accurate summary of what I did 20 minutes ago. I'm actually pretty optimistic about BTC in the long term, just don't want to ride the roller coaster in the short term.
