Deradon

Question for any aviation expert: Would TCAS be triggered at such a low altitude on departure?

Found this in the GPT-5 Announcement:

> Availability and access > GPT‑5 is starting to roll out today to all Plus, Pro, Team, and Free users, with access for Enterprise and Edu coming in one week. Pro, Plus, and Team users can also start coding with GPT‑5 in the Codex CLI (opens in a new window) by signing in with ChatGPT.

There was not really a place to put it into the rails doc. But I put a comic strip as a tribute to _why into a related blog post: https://cult.honeypot.io/reads/why-ruby-on-rails-is-not-dead...

TDD = Test Driven Development

It's not comprehensive documentation, it's a process of software development. Start with the most simple test first, make it green via the most simple implementation, refactor. (Red/Green/Refactor). Repeat until you can not adjust your tests/specs and implementation anymore.

Doing TDD you'll not create comprehensive documentation upfront but will switch your testing- and implementation-hat every few minutes.

For ruby projects where I could simply put the "new test" in a new file I do this:

1. Create new test (e.g. "spec/reproduce-bug_spec.rb")

2. Ignore it locally: `echo "spec/reproduce_bug_spec.rb" >> .git/info/exclude`

3. Run bisect (something like: `git bisect run rspec spec/reproduce-bug_spec.rb`)

If running the test gets more complex (e.g. installing dependencies as they might change travelling through history), I usually create a wrapper script (and ignore it) to bisect-run-it.

Offtopic but related:

Conventional commits: https://www.conventionalcommits.org/en/v1.0.0/

Another comment already mentioned the `.git/info/exclude` directory. For completeness link to the online docs: https://git-scm.com/docs/gitignore

git will take 3 files into consideration for "ignoring" files:

> $XDG_CONFIG_HOME/git/ignore, $GIT_DIR/info/exclude, .gitignore

How I use them:

* ~/.gitignore: stuff I want to ignore everywhere (`/myNotes`, `.DS_STORE`, ...)

* <project>/.gitignore: stuff that should be ignore for this projects and shared with others

* <project>/.git/info/exclude; stuff for this project that only I want to ignore

** this is also super useful in combination with `git-bisect`

Disclaimer: I'm working at honeypot (but not involved in the documentary at all)

You're right. What I've got is NOT the original. I was misled by the almost identical look, wow. (got a FlyingGooseProduct here)

Here in Germany I can still get it in almost every supermarket. So I don't know if it is the EU blocking imports.

In the mid 90s my parents and me were having a 2-day trip from eastern part of Germany to Paris in a "Trabbi". It was loud as hell inside the car. And still, I don't know why, I really liked this trip and like the look of this car a lot.

So maybe to explain myself: I'm used to scan through the homepage and open link and comment side by side for a few things that I think are interesting to me. While reading through it, I might get interrupted. So I might come back to a link a few hours later. So lets say, I open up the extension page and forgot the initial context. So for me, it could theoretically happen that I install this extension cuz I assume links posted at HN to be safe.

Imo, it's not a good idea to directly link to the extension as one might accidentally hit the "Add to chrome" button. (e.g. when coming from the homepage and not peeking into the thread here)

I'm running my teamspeak instance within an LXC container on my physical host. So the only IP I do see is good old home (127.0.0.1). But admins better not use the IP-ban feature in this setup ...

And according to the twitter-bio of the individual, who brought this up, he's related to Red Hat, which are also affected [^1].

[^1]https://github.com/RedHatInsights/compliance-backend/pull/79...

Wow, I'm kinda impressed of all the negative comments here.

What's making a short and focussed daily synchronization meeting (aka: Daily/Standup) useful for me:

* Short and focussed, 15min max, no excuse

* Focus on impediments and try to figure out if the team can help.

* VERY short update on what I'm planning to do today (to make synergies visible)

* And the least important one I'd skip quite often: Short update on what was done yesterday. (Looks like, lot of ppl are focussing on this one)

Actually, for me it's the other way round. Sometimes I write german words like "BratwurstBratGerät" (UpperCamelCase)

It's my default. On the left buffer I've got the implementation, on the right buffer I've got the spec/test.

I'd structure the Dockerfile in another way with the "python:3.8-alpine" approach.

E.g. something like:

  FROM python:3.8-alpine
  
  RUN apk add --no-cache --virtual build-dependencies gcc build-base freetype-dev libpng-dev openblas-dev && \
    pip install --no-cache-dir matplotlib pandas && \
    apk del build-dependencies

This way you won't keep the build dependencies in the layer and the final image. Maybe not all of the packages are build-dependencies, but at least there is no need to keep the gcc and build-base package around. Long story short, wrap your "pip install", "bundle install", "yarn install" around some "apk add .. && apk del" within one RUN.

Yes, it would still compile for quite some time, but the final image size is not "851MB" but "489MB". Still larger than the "363MB" of the "python-slim" version. Guess "pip install" will keep some build artifacts around?

> Committing the red test and the fix to the test in two commits makes the bug and its fix easy to review.

I've done this in the past. Then I started to use `git bisect` and having a red test somewhere in your commit-history is a killer for bisect. So now I tend to include both, the test and the bug-fix, within one commit.

It is explained at the top-level document: https://google.github.io/eng-practices/#terminology