51–60 of 91 posts
Thoughts about serving pure text (not HTML) so that someone can pull this using a curl command, awk the output and do various things with it? Wish more sites did that.
OOI, would you expect the output to include a single days weather (like the site does now), multiple, or options for both?
Thoughts about serving pure text (not HTML) so that someone can pull this using a curl command, awk the output and do various things with it? Wish more sites did that.
I’ve had a few pieces of feedback for plain text, and it’s definitely something I’ll look at adding. OOI, would you expect the output to include a single days weather (like the site does now), multiple, or options for both?
Earlier quoted context omitted.
Looking at chrome dev tools, it looks like it might be the custom font causing the delay. I'm not sure exactly why though.
Interesting, I’d have naively assumed that’d be cached after first load by Chrome. Definitely one to investigate further.
London UK is currently 'forecast/zRKY7wMc' you could label all population centres >100k like 'forecast/uk-london', 'forecast/cn-london', etc
Still, great project! Definitely fulfils my desire for minimalism in all things.
Is there a reason why the URL parameters are obfuscated? I think it would more user (and SEO) friendly to have at least the place names in the URL, e.g. brolly.sh/forecast/united-kingdom/yorkshire/york. Still, great project! Definitely fulfils my desire for minimalism in all things.
The short code in the URL is generated at search time, and maps to a location name, lat/long, altitude etc. within a table. It’s generated off of the location name, so two people searching for the same place get the same short code.
The short code enables a forecast lookup to be a SQLite DB read, followed by a single API call for the forecast.
A more descriptive URL would have required two sequential calls - one to figure out the lat/long and/or place name, and another for the forecast. This wasn’t a huge speed problem, but I struggled to find geocoding APIs with generous free tiers or reasonable low volume pricing. It would have also made the forecast at a given URL somewhat non-deterministic, as the geocoding API could change its output or preferred result over time.
Short codes quite possibly wasn’t the right solution. It’s definitely something I’ll think more about. Thank you!
Is there a reason why the URL parameters are obfuscated? I think it would more user (and SEO) friendly to have at least the place names in the URL, e.g. brolly.sh/forecast/united-kingdom/yorkshire/york. Still, great project! Definitely fulfils my desire for minimalism in all things.
It’s a good question. Initially, the URL was lat/long values, and then I did try place names. I ended up with the short code approach to minimise API calls to downstream services. The short code in the URL is generated at search time, and maps to a location name, lat/long, altitude etc. within a table. It’s generated off of the location name, so two people searching for the same place get the same short code. The sho…