HN user

jrrrr

238 karma
Posts1
Comments63
View on HN

Maybe this is a different use case for code generators from what you have in mind? This isn't one-time upfront scaffolding, it's a recurring part of the development process.

When email templates are edited in the external service, you run the generator to pull in the latest structure, and it breaks your build with new type errors.

This is great!

For years when discussing displays and computing ergonomics, I've claimed that I look forward to the day when my screen doesn't need to emit light, and maybe using it can feel more like paper.

Reading this makes it seem less sci-fi future, and possible today if we can get enough interest/momentum.

I'm trying to think of practical places to start for a sellable product. I love the Paperterm idea, but recognize that it's super niche. Maybe something focused on distraction-free writing?

Make is arcane and it gets really gnarly when you use it to describe a large build.

I wouldn't want to use it for its intended use without first looking hard at modern alternatives. (perhaps starting here? https://github.com/ninja-build/ninja/wiki/List-of-generators... )

But for solving the problem of "where should we keep our developer command shortcuts?" (which you might answer with "shell scripts" or "a Rakefile"), I've found Make to be pretty great!

Perfect, thanks, that's what I was looking for (and none of the news coverage seems to mention).

So when you want to sell a tweet, Valuables verifies who you are and that you own the account (presumably), they produce one certificate and promise never to produce another, and then it goes into the blockchain.

So now there is one and only one entry for this tweet in the Valuables Twitter namespace, but there can be more from other organizations and on other blockchains.

It's going to become even more of a collectors' item when Valuables shuts down, or Twitter changes their URL scheme, or we're not using https:// anymore ;)

I can imagine a policy mandating that for all commercial software, source code goes into escrow for automatic release 10 or 20 years later.

The company doesn't have to be around anymore, rights don't have to be negotiated, etc.

Short of that I wish more companies would do it voluntarily. I'm not into id games, but they're one example that comes to mind.

Maybe they problem is the word "need". How do you interpret the word in this context? I read it as "are legally required to", which is a thing that can be true or false.

I love this idea.

Some ideas to take it further (maybe on the blog):

- Products for which there is no good bifl version, and advice on what to aim for instead. (E.g. the ecologically least-bad disposable one?)

- Other purchases with longer time horizons and tradeoffs. (E.g. roofing material, cars)

Also, do you have a plan to wrestle with the complexity of a product's revision over time? For example I heard Vasque boots got way worse when production went overseas. Pyrex glass types, etc. One thing I'd hope to glean from your site is how to identify the good version of a thing, and to know whether I can still find a new one or need to look for a used one.

Looks like that board is the sole option for Thunderbolt && AMD && ITX. Bummer that there are no options with passively-cooled B550 chipsets.

I do something similar to the post's two-cable configuration:

- Mac to Caldigit TB dock to two displays. - PC to one of the displays - Keyboard and mouse to a USB switch, which connects to the PC and the TB dock

It's kind of a pain to manually flip both the USB switch and the monitor's input.

This app can theoretically help by programmatically toggling the display's input when particular USB devices are dis/connected:

https://github.com/haimgel/display-switch

.. but compatibility is spotty, relying on a rarely-used hardware feature in the display that seems to not be reliably implemented ("DDC/CI").

It defeats _one_ of the purposes of using Docker for development.

I expect that the official M1-supporting Docker Desktop will eventually, given a dual-arch image, allow you to choose which architecture to use. (One would run natively, the other under emulation)

There are situations where I'd use this feature, but 90% of the time I'd be fine using arm images locally and deploying x64.

(I could also imagine this working the other way -- an x86 dev machine and an arm deployment target -- which I think to some degree is supported by Docker today)

Halide Mark II 6 years ago

What's the backstory here? (why did you have to settle on free-with-immediate-IAP?)

Thanks for doing this! I too have a lot of nostalgia for this game, which had a depth to it beyond most of the other stuff I was playing at the time.

What was the porting process like? Use any tools to assist with it?

Re: proxy security concerns:

Unlike GitHub, most of them don't even bother proxying the image to hide IP, referrer, and browser agent. If you want to allow external images on your site, you must proxy them and hide everything about a person who requested it. A person with bad intentions can trick a victim into opening your profile that looks completely legit and detect his IP and a browser.

Can you explain this in more detail? Given a profile host that doesn't proxy, how does that attack work?

ESLint 7.0 6 years ago

Well, it's on one line for starters ;)

Looking at one suppression in one place it doesn't make a big difference.

It will help a lot with whole-project search results, though, if you're trying to e.g. fix all the places you had to suppress X because of Y.