anschwa

You can develop color at home too, it's pretty much the same process and effort but with different chemicals.

On macOS, you can enable window dragging by holding down the Control+Command keys with this command:

    defaults write -g NSWindowShouldDragOnGesture -bool true

I use this with "three finger drag", and resizing at the window border hasn't been much of an issue for me.

Great question! In my experience with ruby on rails, the application runtime is so dynamic, that even unit tests may not be reliable if run outside the production image.

I think normally this isn't much of an issue because other automated/manual integration testing in the staging environments will catch any major problems, to your point.

Another example would be for browser testing via chromedriver. I've usually seen this implemented along side unit tests (i.e., prior to the build phase) but since it generally serves as an integration level test for many applications, this has lead to issues due to the testing and production environments being out of sync.

I think multi-layer Docker images are a compelling solution to this, but it's not usually how I've seen it implemented.

Instead, I've typically seen that test and prod environments are manually maintained. Sometimes these are two separate Dockerfiles or some shared CI environment managed by different teams.

I think it's common (and important!) to build your "production" image once and deploy it into a dev/staging environment first. This means there are no re-builds between deploys to each environment.

However, I think it's less common to run automated testing within the same Docker image you build and deploy to these environments.

This is challenging because you probably don't want to include any build/test related packages in your production image (or layer) but you still want some level of confidence that your CI and Prod environments are the same.

I have often see builds pass automated testing but fail after deployment because our production Dockerfile/layer was missing packages or shared libraries that were present in the CI environment.

One of my professors would often refer to this struggle as taking place between the Nihilists and Unitarians.

Personally, I would like to see a markdown spec that eliminates parsing ambiguity by restricting the "edge-case" features that HTML is really much better at describing in a standard and structured way.

I think we could pick one way to handle emphasis, lists, and code blocks that covers a specific and predictable 80%.

Anything that becomes hard to describe without including additional notation to the grammar is probably best suited to be left as HTML, as was the intention behind markdown to begin with.

Yes! Using org-publish with htmlize is wonderful.

Wow! Occur is the gift that keeps on giving. That's great!

Yes! wdired and wgrep are really fun.

It's amazing how Emacs utilizes buffers to offer a very powerful and consistent user interface.

I think some other compelling examples are compilation-mode and magit.