Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Brolly, a plain-text weather forecast site

brolly.sh

Post reply on HN
Print view View original

61–70 of 91 posts

Re: Show HN: Brolly, a plain-text weather forecast site

#61

Post by Pikamander2 »

jsax wrote: post #12
8ig8 wrote: post #11

Looks great. One thing that initially tripped me up, I searched "Raleigh, NC" and got no place found. "Raleigh" worked.

That’s frustrating, thank you for the feedback. I’ll take a look at improving the search and potentially switching out the API provider. I currently use open-meteo as I was already using it for the weather forecast (it has a great weather API), and it made sense at the time to keep with a single provider.

Similarly, "Orlando" returns a bunch of results but "Orlando FL" returns none.

It would also be nice if it suggested results before you finished typing. For example, if I've typed out "orl", then Orlando should be the top suggested result.

Re: Show HN: Brolly, a plain-text weather forecast site

#63

Post by esseph »

echoangle wrote: post #60
jsax wrote: post #59

Earlier quoted context omitted.

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…

I don’t get that reason, couldn’t you just use the location name as a field in the database just like you use the short code right now? Where’s the additional API call on lookup coming from?

Re-read their response. They answered both these questions.

Re: Show HN: Brolly, a plain-text weather forecast site

#64

Post by comradesmith »

My only comment is that the time of the report under the date was a little confusing, for a moment I thought that was the current time. Maybe you could add `as at` so it differentiates the time of the observation window versus the current time?

I'll try using this as my go to over the next week :) thank you for making this.

Re: Show HN: Brolly, a plain-text weather forecast site

#67

Post by simonjgreen »

This is really pleasing to use, lovely work :)

Also, wanted to note I appreciate your stance on AI:

> I manually designed the site, defined its architecture, structure etc.

> I have however used AI to implement significant portions, whilst keeping the most interesting bits to work on myself.

> I have mixed feelings about AI. I wouldn't have had the time to build this site without it, and use it heavily in my day job to improve velocity. But, there are also points where I deliberately avoid using it, either to keep the joy of focusing on a problem, or to make sure I'm not accidentally AI 'doom scrolling' my way through life. Everything is a balance.

Re: Show HN: Brolly, a plain-text weather forecast site

#68

Post by simonjgreen »

smnscu wrote: post #42

I was thoroughly confused at why the website was showing the weather for York. Since I studied there (and it's straight up a lovely place), I visit quite often and subsequently check the weather. I thought I had set it but couldn't remember doing so. As someone else said, this being text-based makes it particularly digestible to LLMs. Out of curiosity, I looked up weather MCPs and stumbled upon this: https://github.c…

From the About page, it’s the authors home

Re: Show HN: Brolly, a plain-text weather forecast site

#69

Post by Svip »

jsax wrote: post #59
Contortion wrote: post #57

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…

How about adding the location information as a suffix to the short code, e.g. `/forecast//united-kingdom/yorkshire/york`? The latter part of the URL is of not use to the site, but is useful for the user.
Post reply on HN