Live data from Hacker News

foo@bar.com

bar.com

171–180 of 301 posts

Re: foo@bar.com

#171
The character’s image is quite frightening.

The Foo reminds me of a whole bunch of British children’s TV shows with characters that gave me many nightmares. Some sort of body horror, I believe.

Re: foo@bar.com

#173

Something that I’m surprised a lot of devs don’t know; there are official domains you’re supposed to use for documentation, testing, etc. They are specifically reserved by IANA for these purposes. Originally I think it was just example.com, but they now have a list of all them: https://www.iana.org/domains/reserved

Related - there are reserved IPv4 and IPv6 addresses for a similar purpose too: https://en.wikipedia.org/wiki/Reserved_IP_addresses . Not just for testing, but for writing documentation and similar too.

Re: foo@bar.com

#175
post #157

Earlier quoted context omitted.

It's not a huge change though. .dev was a new, never-launched TLD, so there were no existing real domain names to break with the addition of HSTS preloading. Established best practice for decades at that point was already to always use real domain names (or subdomains thereof) or specifically reserved test domains/TLDs (see RFC 2606, published in 1999) for testing/development/local networking purposes. So yes, we did…

Were you somehow unaware of the many, many, many people who used .dev in their local environments? You must've had some idea, since the initial plan was to use the .dev TLD for exactly that within Google. I've always hated Google for egoistically claiming this tld, and ICANN for letting them.

Basecamp’s Pow project comes to mind.

It enables zero config local development configuration, whereby at the time it would make your locally running dev server available on .dev

So instead of having to spin up a local server and then visiting say 127.0.0.1:3000,

I could instead just visit myappname.dev and it would show me what would previously show on localhost or it would spin up a server first for that app then show it to me.

They switched to .test in response to google’s change.

Official site: https://pow.cx

Thread on change from .dev to .test https://github.com/basecamp/pow/issues/386

Re: foo@bar.com

#176
post #157

Earlier quoted context omitted.

It's not a huge change though. .dev was a new, never-launched TLD, so there were no existing real domain names to break with the addition of HSTS preloading. Established best practice for decades at that point was already to always use real domain names (or subdomains thereof) or specifically reserved test domains/TLDs (see RFC 2606, published in 1999) for testing/development/local networking purposes. So yes, we did…

Were you somehow unaware of the many, many, many people who used .dev in their local environments? You must've had some idea, since the initial plan was to use the .dev TLD for exactly that within Google. I've always hated Google for egoistically claiming this tld, and ICANN for letting them.

This attitude is the reason I refuse to use Chrome and only recommend the alternatives.

Re: foo@bar.com

#177

Earlier quoted context omitted.

After ".py", use " ?" (the space is important) to force the search in firefox.

Using a question make in front of the term is traditionally how some browsers trigger search. They usually have a jeybconbe to add it automatically. For example, in firefox and chrome ctrl-l will clear the URL bar and put the cursor and focus there to take you to the location you enter, and ctrl-k will do similar but pre-fill the location bar with a preceding '?' so a search is triggered on the input. These shortcuts…

What's a "jeybconbe"? It's a googlewhack for this thread.

Re: foo@bar.com

#179
post #137

Earlier quoted context omitted.

if we could go back I wonder if it would be better if we had required a leading dot in domain names ".google.com"

Or if browsers weren't trying to be too smart enough and use the same box for both searching and addresses. Trips me with .py files all time time.

Press Ctrl+K and browser will be forced to search.

Re: foo@bar.com

#180

Earlier quoted context omitted.

I've personally run into the .zip problem thanks to browser's omni address/search/chocolate bars. I intend to search for a zip file whose name I know but the browser "helpfully" realizes the term includes no spaces and ends in dot something and attempts to treat it as a URL. A simple workaround is to add a preceding space or something like inurl: but that's isn't an automatic behavior so whoever owns mlpdwarfporn.zip…

if we could go back I wonder if it would be better if we had required a leading dot in domain names ".google.com"

Or just required the use of the true FQDN - "google.com."
Post reply on HN