Can you share more about the "sustainable packaging"?

Yes! - Our packets are made from 4"x6" aluminum, FDA-approved packaging. - We ship in thermal bubble mailers (also aluminum) inside of recyclable boxes with compostable liners. - We include ice packs in each order that are reusable. You can also send those back to us if you don't want to keep them!

The comic version of this is pretty great, too: https://twitter.com/sketchshark/status/941096945308770304

This is something I've considered doing for years after dealing with the likes of Clickbank, etc. I'd love to pick your brain for your requirements. How can I get in touch?

alex@viphawk.com

Fun fact: The population of the world grew ~5x in her lifetime, from ~1.6B to ~7.5B.

Terrifying

This is awesome! Would love it if I could punch in my address/zip and get an idea of what to plant (I don't know what my climate qualifies as).

Compared to React, what isn't available in Preact?

Last time I checked you couldn't use contexts yet.

Thats a good thing.

Context is not a good feature, and even the developers didn't want to write documentation for it because they didn't want people to use it. https://github.com/facebook/react/issues/580

As people adopt external state containers, like Flux and Redux, it becomes increasingly impractical to bucket brigade chunks of data and callbacks to the leaves of the component tree via props. Some sort of delivery mechanism that doesn't couple in intermediate components is pretty critical to avoid having to maintain an unbounded amount of glue code. Context isn't without its kinks, but it's pretty useful in cutting boilerplate and decoupling components. The one thing I don't buy is that it's somehow worse than props from an architectural perspective (it's often compared to global variables, which makes little sense to me).

Then how would something like react-redux work without context?

It can already work without contexts. You just pass a store instance via props.

I don't like contexts either :(

Yup. I've successfully added contexts to Preact, but I still am not 100% sold on the value. Thankfully, simply supporting them doesn't add much bloat.

Wait until you run out of disk while running PostgreSQL with dokku. That's an adventure I don't want to have to repeat.

You can run out of disk space using anything. Might be worth setting alerts on Disk/Memory/CPU for your servers in the future (New Relic has that).

Dokku is currently meant to manage the application deployment lifecycle, not everything related to server management.

While that's true, I think the discussion in that issue has gone more towards HTTPS support for custom domains.

> While that's true, I think the discussion in that issue has gone more towards HTTPS support for custom domains.

A huge number of those "+1 for HTTPS on custom domains" don't seem to understand/appreciate the difference in providing HTTPS on the *.github.io (one wildcard cert) vs. HTTPS support for custom domains.

The latter would require an interface (UX being key here) and storage for uploading your own domain certificates to GitHub, which is nothing like any other part of GitHub right now. I also presume that most of these "+1's" would want this service to remain free.

You could always use CloudFlare directly for that... I would presume that their underlying connection to Github is very close and reliable in terms of risk for MITM.

Even better, you could CNAME your custom domain into the *.github.io domain, which is protected by a wildcard https.

So you traffic between CloudFlare and GitHub will also be secured.

Last I checked, this doesn't actually work with the way *.github.io is set up.

I wonder if letsencrypt will allow that to become practical?

Great tip, but unfortunately that doesn't work for private repos.

Maybe a more apt title would be "Things I would fix if I worked at GitHub". :)