Nah, bad idea. The timeframe of an active connection really varies by age and type. Some important connections are once-every-few-years communications. A year, or two years, etc is too arbitrary.
The LLM isn’t contributing garbage, the user is by (likely) not testing/verifying it meets all requirements. I haven’t yet used an LLM which didn’t require some handholding to get to a good code contribution on projects with any complexity.
It’s been a while since I georeferenced in qgis, but there used to be some great plugins. Looks like some of those are gone now, and the core module has improved a lot. This newer plugin looks promising, though: https://github.com/cxcandid/GeorefExtension
Quick benchmark of pmtiles directly in maplibre vs served tiles, both via Bunnycdn and 5 areas sampled using same style.
Total impact on page end to end load time: 39ms longer with cached range requests from pmtiles than cached tiles.
Individual requests are comparable in the 20-35ms range, so the slight extra time seems to be from the additional round trip for range headers (makes sense).
Interesting, I should benchmark this. I have only used Bunnycdn so far and latency seemed similar to most tile providers like Maptiler and others (but a very limited test). This was using the full planet pmtiles file.
Bunnycdn also makes it easy to prevent downloading the entire file, either in case you care about anyone using it or just want to prevent surprise downloads for those exploring network tab.
Curious how this would have compared to a static pmtiles file being read directly by maplibre. I’ve had good luck with virtually equal latency to served tiles when consuming pmtiles via range requests on Bunnycdn.
100% this. To echo another poster below, it's really important to read the Supreme Court's own words here.
>"The Government’s argument, moreover, implies that it could deport and incarcerate any person, including U. S. citizens, without legal consequence, so long as it does so before a court can intervene. "
From https://www.supremecourt.gov/opinions/24pdf/24a949_lkhn.pdf
I suspect that is one of the main reasons behind the order. It's very obvious that citizen vs legal resident matters very little here, if due process is not given.
Sadly, Claude 3.7 is still failing pretty hard on Svelte 5 even when provided latest docs in context. It just fails more confidently and further into otherwise decent code than 3.5. Ex: built a much more complex initial app, but used runes incorrectly and continued to use <slot>. Even when prompted with update doc snippets, it couldn't dig itself out of its hole.
We really still need a better unified workflow for working on the cutting edge of tech with LLMs, imo. This problem is the same with other frameworks/technologies undergoing recent changes.
Likewise, tried a couple basic things and nearly at $1 already. I can see this adding up fast, per the blog post's fair warning below. Coming from Cursor, I'm a bit scared to even try to compare workflows...
>Claude Code consumes tokens for each interaction. Typical usage costs range from $5-10 per developer per day, but can exceed $100 per hour during intensive use.
Reread the blog post, and I suspect Cursor will remain much more competitive on pricing! No specifics, but likely far exceeding typical Cursor costs for a typical developer. Maybe it's worth it, though? Look forward to trying.
>Claude Code consumes tokens for each interaction. Typical usage costs range from $5-10 per developer per day, but can exceed $100 per hour during intensive use.
I wonder if they will offer competitive request counts against Cursor. Right now, at least for me, the biggest downside to Claude is how fast I blow through the limits (Pro) and hit a wall.
At least with Cursor, I can use all "premium" 500 completions and either buy more, or be patient for throttled responses.