anschwa

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

    defaults write -g NSWindowShouldDragOnGesture -bool true

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.

You can't bring up Feyerabend without mentioning Imre Lakatos. The "methodology of scientific research programmes" is another fun read that takes the matter of demarcation a bit more seriously than AM.

For example, Lakatos isn't satisfied with "anything goes" because it fails to consider the political and social consequences of being unable to recognize science from pseudoscience. For Lakatos, demarcation is necessary to maintain a "standard of objective honesty", and avoid falling into an "intellectual decay".

Overall, Lakatos is much less provocative than Feyerabend, but is equally invested in picking apart the historical nuances of scientific progress brought into question by Popper and Kuhn.

Rails is still relevant and has only gotten better.

I recently picked up the Fellow Ode for myself. I'm very happy with it so far and it's working exactly as advertised. Quiet, consistent, and very fast.

Blink[1] is a really cool open source app that will give you a shell on iOS and allow you to SSH into another machine. You can install it yourself, or purchase from the App Store.

If you want to use another computer you own, rather than a server in the cloud, Tailscale[2] will let you easily connect when away from home.

- [1] https://blink.sh/

- [2] https://tailscale.com/

The moka pot is super cool and I thought it made great coffee...until I discovered that I preferred almost every other possible brew method.

The moka pot is very hard to dial in and almost always burns the coffee. It requires care, focus, and attention. They're much more inconsistent than pour over and even the lever espresso machines I've used are less work.

I think moka pots are fun and worth experimenting with but I find it hard to believe people really love the results. But if you are always adding milk and sugar, then I can definitely see the appeal.

Agreed! I spent way too long doing flexbox layouts before I discovered 'gap'.

Looks great!

https://based.cooking/ might be another good source of recipes if you're not already using it.

Arch is great, although I think fedora does a much better job at providing a no-nonsense Linux workstation and would make for a smoother transition from macOS.

I read this somewhere about how to do estimates and it has stuck with me:

"Double the number and increment the unit."

This is a simple formula to calculate how long something takes to go from idea to production.

So, 3 hours becomes 6 days; 2 weeks is 4 months, etc.

Enjoy!

You better believe it. This was exactly my experience as a TA in my College's computer science department from 2014-2018.

It's not incompetence though, as the article points out, we've moved beyond an intimate understanding of the filesystem being a prerequisite for using computers.

Using interactive browser based environments like jupyter notebooks have made needing to deal with files even less of an issue.

Whitespace is definitely a legitimate critique of python.

The fact that people have learned to live with it or just ignore it is pretty irrelevant in my opinion.

Significant whitespace means I can't copy+paste without introducing bugs or breaking the code. It means code formatting becomes more complex to automate. It's seriously the dumbest language feature to defend and should be pretty acceptable to admit was a mistake.

I agree that having whitespace sensitive scoping isn't a compelling enough reason in itself to avoid python, but it is hard for me to understand how python programmers insist on defending it as a great design choice that "improves readability". To me that indicates an inexperienced developer who is unfamiliar with the alternatives.

I feel similarly for people who reject (or say they hate) static types and compilers.

It sounds like you are looking for an excuse to give org-mode a chance.

Github will render org-mode documents now, so there's that.

Don't be afraid to give emacs a test drive, it's very possible to avoid getting sucked into the ecosystem and configuration if you aren't interested.

Either you'll decide it's what you've been looking for, or you prefer your current approach. Win-Win.

I'm not sure I agree keybindings were/are the significant factor. The editors have a completely different history and their authors come from very different backgrounds.

The way I see it, emacs is really an idea.

Vim is a text editor that grew into an ecosystem of people bolting on additional functionality. While extensibility is possible, it's nowhere near as transparent and consistent as the emacs environment. In fact no system I know of comes even close.

Emacs paved the way for the features we take for granted in graphical applications like undo, copy+paste, search, find+replace, spell check, project navigation, code completion, auto-formatting, and of course, plugins.

These days, indeed much of the appeal is gone if all you're doing is comparing features at a surface level.

Yes, it looks like all editors "do the same thing" but really emacs is quite different in spirit.

And you can play it back!

See "info scriptreplay"

Another cool thing about undo in Emacs is that it's context aware.

By default, you can select any block of text and the undo command will cycle through the changes only from that region of your buffer.

I was running Debian stable with xfce4 (4.12.5) for the last few years. A few months ago, chromium and other applications started to give me major rendering problems, becoming completely transparent when switching virtual desktop "workspaces".

I decided it was time to get with the times and try out GNOME on wayland. While I would have preferred to stick with xfce, Debian stable does not make it convenient to upgrade to their latest version, 4.16.

I'm using a T480 Thinkpad and I'm sure my GNOME version is similarly out of date, but wayland has been performing well enough so far.

However, at this point I'm looking to migrate to Fedora when I get the time. I'm tired of fighting against the bizarre nerd carnival that is the Linux Desktop.

These are my installation notes: https://github.com/anschwa/debian-thinkpad-install

Intuitively, I'd expect that NGINX serving static content would tend to scale fairly linearly up to the saturation point, and then get rapidly bad

That was essentially what I saw. I was serving very minimal dynamic content that had some random sleeps. I even reached out to the NGINX mailing list and got a similar response about how they wouldn't expect much measurable difference. However, I still think it would be possible to construct a better test.

I did my undergrad CS thesis on this topic and implemented a "power of two choices" load balancing module in NGINX.

When simulating load distribution across servers, two-choices does an outstanding job at keeping things evenly distributed. However, I was unable to observe a meaningful difference between load balancing algorithms when measuring request latency from servers under load.

I think there is still a lot to be gained from exploring two-choices, but coming up with an appropriate strategy for "real-world" performance benchmarking is quite challenging.

Wow! Happy to have shared a similar experience on Isle Royal in the summer of 2010. One of the highlights of the trip for sure!

I think few people know the difference, so they say backslash when they mean forward slash.

I'm not exactly sure I understand the use-case, but as far as the example used in the article, shell-command-on-region accomplishes the same kind of thing. Why not leave the "generation code" as a comment in your file the same way cog does?