LukeLambert

2 年前議論

The big problem with statement-based replication is that many queries are non-deterministic. e.g. Inserting a row with current_timestamp or random()

LukeLambert

2 年前議論

Yes, it was the Ghost URL. Thank you for correcting it! I read just about every post, so I have a lot of catching up to do.

LukeLambert

2 年前議論

This is really cool and I can't wait to read all about it. Unfortunately, I've missed a month of blog posts because Cloudflare changed their blog's RSS URL without notice. If you change blogging platforms and can't implement a 301, please leave a post letting subscribers know where to find the new feed. RSS isn't dead!

LukeLambert

3 年前議論

I don't think Starlink has any data caps. On average, the tests download 140 MB and upload 15 MB each run (560 MB and 60 MB daily).

LukeLambert

3 年前議論

Note that the timestamps are UTC, while Texas is UTC-6:00 during Standard Time and UTC-5:00 during Daylight Saving Time. The biggest dip is during prime streaming hours.

LukeLambert

3 年前議論

Yep!

  speedtest -f json -I eth0

I also test the WISP connection on eth1

LukeLambert

3 年前議論

My parents in rural Northeast Texas use Starlink as their primary connection (they have a WISP as failover). Since Sept. 2022, I've been running automated speed tests four times a day (1 and 7, AM and PM). Speeds vary a lot throughout the day, but average about 100 Mbps down by 10 Mbps up.

https://gist.github.com/LukeLambert/dd722e49bc773bcb27e859d9...

LukeLambert

3 年前議論

Can someone explain what it looks like from a user's perspective when an article is blocked? Is there an error message? Limited reach? Plain link instead of rich preview?

If the publishers don't want their photo, headline, and first sentence or two appearing without payment as a rich preview on Facebook, well ok. I think it's a stretch, but I can at least see their perspective. It's worth noting that publishers are already in control of that preview with Open Graph tags.

However, if they want to get paid for an unadorned <a> tag, that completely goes against the spirit of hypertext.

LukeLambert

3 年前議論

I think Simon has a lot of experience solving hard problems: https://simonwillison.net/about/

LukeLambert

3 年前議論

With Messages and Music in particular (and perhaps other apps), you can sign into a different Apple ID than the one used for the system-level iCloud account.

LukeLambert

3 年前議論

That's likely due to the page having a canonical URL meta tag:

  <link rel="canonical" href="https://www.twintown.com/collections/acoustic-guitars"/>

LukeLambert

3 年前議論

  javascript:prompt('URL',window.location.origin+window.location.pathname)

Edit: But be aware that some sites (like this one) need the parameters in the query string.

LukeLambert

4 年前議論

Thank you for following up. IMHO, object-fit is not the right model for server-side image manipulation, since its behavior is only specified when both width and height are supplied. I've also never seen a real world use case for stretching, squeezing, padding, or enlarging images on the server. That should be done on the client. I mentioned some of the same issues on the Cloudflare forum when they announced an image resizing product based on object-fit.

I believe all resizing operations a user might realistically want can be achieved with three parameters: width, height, and crop. Additional x and y parameters (floats between 0.0 and 1.0) could be used for setting the focal point of the crop box.

Examples:

  source.jpg?width=400

Iff source width is greater than 400px, scale down to 400px wide.

  source.jpg?height=300

Iff source height is greater than 300px, scale down to 300px high.

  source.jpg?width=400&height=300

Iff source width is greater than 400px or source height is greater than 300px, scale down to fit within a 400px by 300px box.

  source.jpg?width=400&height=300&crop=true

Crop source to a 4x3 aspect ratio. Iff result is larger than 400px by 300px, scale down.

LukeLambert

4 年前議論

In nearly two decades developing for the web, I've never found a good reason to enlarge an image server-side, so thank you for anticipating that footgun. So many of your competitors get it wrong.

However, it's unclear from the docs [0] if one of the most common use cases is supported: requesting an image at a specific aspect ratio while not exceeding a maximum size.

For instance, I want a 1600×900px hero image at the top of my blog posts, but my source image is only 1200px wide. I request:

  transform: {
    width: 1600,
    height: 900,
    resize: 'cover'
  }

Will the returned image be 675px tall, maintaining the 16×9 aspect ratio I want?

A few more notes:

The blog post states "default mode maintains aspect ratio and the resize mode is fill", but the docs say that cover is the default mode.

The docs say, "If only one [width or height] parameter is specified, the image will be resized and cropped, maintaining the aspect ratio." I believe that with only one parameter, you could either resize or crop, but not both. I hope it's resize.

For cropping modes, is it always from the center? Are there plans to support other "gravity" modes?

[0] https://supabase.com/docs/guides/storage/image-transformatio...

LukeLambert

投稿

Fly.io is deprecating 17 regions

We're Cutting L40S Prices in Half

Removing data transfer fees when moving off Google Cloud

An APPR Claim with Air Canada

Tell HN: My Disney account works on at least 31 domains

After four years of SMR storage, here's what we love–and what comes next

コメント