4 ms·

Another ASCII art weather (forecast) utility, but in Go: https://github.com/schachmat/wego https://github.com/schachmat/wego

flaie 11y ago
This is much much better. Closer to "beautiful" than the one featured here.
- lectrick 11y ago
  Yeah, it's beautiful if 1) you think mutable variables are beautiful 2) you think stuffing everything into one file is beautiful 3) you think defining functions at the root namespace is beautiful 4) you think consecutive repeated property accesses stuffed into a consecutively repeating boolean check like this are beautiful: if h.Time == "0" || h.Time == "100" || h.Time == "200" || h.Time == "300" || h.Time == "400" || h.Time == "500" || h.Time == "600" || h.Time == "700" || h.Time == "1400" || h.Time == "1500" || h.Time == "1600" || h.Time == "2300" 5) if you think embedding ANSI color codes across all strings instead of centralizing all that ugliness somewhere is beautiful 6) if you think not separating your command-line-handling code from your problem-modeling code is beautiful (see: Hexagonal Architecture http://alistair.cockburn.us/Hexagonal+architecture http://alistair.cockburn.us/Hexagonal+architecture) 7) If you think having no fucking test suite to speak of, given all that mangled mutating code is beautiful (to me this is the MOST egregious non-beautiful thing in the entire "project") Then, yes. WeGo is beautiful. Frankly I'm shocked that what people call "beautiful" can differ that fucking much.
  - commentzorro 11y ago
    I think the parent was referring to the console display output rather than the code itself.
    - lectrick 11y ago
      lol. then I guess I will step off my pedestal and agree. I mean... I think Figlet does a better job than all of these, but anyway
djm_ 11y ago
Can anyone explain why a dependency of this app is a "working Go environment"? I thought one of golang's selling points was the fact that it created a simple binary. As far as I can tell, the Go environment is simply being used as a cheap installer, is that correct?
- laumars 11y ago
  Because he's sharing the source code rather than a compiled binary. It's no different to having make + gcc listed as a dependency for C++ code.
  - frou_dh 11y ago
    Strictly there is a little hindrance for the non-gopher user because this won't work until they set up a Go workspace, i.e. decided where they want GOPATH to be, set that, and added $GOPATH/bin to PATH to have the executable be runnable. $ env -i $(which go) get github.com/schachmat/wego package github.com/schachmat/wego: cannot download, $GOPATH not set. For more details see: go help gopath
    - laumars 11y ago
      Indeed, but that's a separate point. The question was why Go was listed as a dependency and my answer was because it's a source code repository. Also, you left off GOROOT from your Go environment :)
      - frou_dh 11y ago
        > The question was why Go was listed as a dependency You may have read it that way but the question was explicitly referring to "working Go environment"
        laumars 11y ago
        Only because that was the terminology used on the Github readme. He was quoting it verbatim rather than asking what environmental variables needed setting. The reason I think this is because he also went on to say "I thought one of golang's selling points was the fact that it created a simple binary." which relates directly to discussions people make about JIT compiled (eg Python, Javascript, etc) vs AOT compiled (eg C++ and Go). It's also worth noting that you're only specifically discussing environmental variables, where as a development environment is more than just that. Aside having your build tools in PATH (and lets not forget that gcc and make need this just as much as go does), you need supporting shells for the ./config(ure) scripts, any source libraries for C++ includes, and so forth. So you could equally use the same "working [language] environment" terminology to describe C++ - or in fact any other programming language too. Which is why I think he was asking why he needed Go installed to begin with.
fit2rule 11y ago
Thanks, wego is very beautiful and quite useful!
iamcurious 11y ago
Unlike the main post, this is a good use of ASCII art. i.e. to show a drawing/symbol not to make numbers more difficult to parse...
ZenSwordArts 11y ago
Wow thanks for sharing.. this is really is beautiful!
tacticiankerala 11y ago
That's really mind blowing! Thanks for sharing this.

flaie 11y ago

This is much much better. Closer to "beautiful" than the one featured here.

lectrick 11y ago
Yeah, it's beautiful if 1) you think mutable variables are beautiful 2) you think stuffing everything into one file is beautiful 3) you think defining functions at the root namespace is beautiful 4) you think consecutive repeated property accesses stuffed into a consecutively repeating boolean check like this are beautiful: if h.Time == "0" || h.Time == "100" || h.Time == "200" || h.Time == "300" || h.Time == "400" || h.Time == "500" || h.Time == "600" || h.Time == "700" || h.Time == "1400" || h.Time == "1500" || h.Time == "1600" || h.Time == "2300" 5) if you think embedding ANSI color codes across all strings instead of centralizing all that ugliness somewhere is beautiful 6) if you think not separating your command-line-handling code from your problem-modeling code is beautiful (see: Hexagonal Architecture http://alistair.cockburn.us/Hexagonal+architecture http://alistair.cockburn.us/Hexagonal+architecture) 7) If you think having no fucking test suite to speak of, given all that mangled mutating code is beautiful (to me this is the MOST egregious non-beautiful thing in the entire "project") Then, yes. WeGo is beautiful. Frankly I'm shocked that what people call "beautiful" can differ that fucking much.
- commentzorro 11y ago
  I think the parent was referring to the console display output rather than the code itself.
  - lectrick 11y ago
    lol. then I guess I will step off my pedestal and agree. I mean... I think Figlet does a better job than all of these, but anyway

djm_ 11y ago

Can anyone explain why a dependency of this app is a "working Go environment"? I thought one of golang's selling points was the fact that it created a simple binary. As far as I can tell, the Go environment is simply being used as a cheap installer, is that correct?

laumars 11y ago
Because he's sharing the source code rather than a compiled binary. It's no different to having make + gcc listed as a dependency for C++ code.
- frou_dh 11y ago
  Strictly there is a little hindrance for the non-gopher user because this won't work until they set up a Go workspace, i.e. decided where they want GOPATH to be, set that, and added $GOPATH/bin to PATH to have the executable be runnable. $ env -i $(which go) get github.com/schachmat/wego package github.com/schachmat/wego: cannot download, $GOPATH not set. For more details see: go help gopath
  - laumars 11y ago
    Indeed, but that's a separate point. The question was why Go was listed as a dependency and my answer was because it's a source code repository. Also, you left off GOROOT from your Go environment :)
    - frou_dh 11y ago
      > The question was why Go was listed as a dependency You may have read it that way but the question was explicitly referring to "working Go environment"
      - laumars 11y ago
        Only because that was the terminology used on the Github readme. He was quoting it verbatim rather than asking what environmental variables needed setting. The reason I think this is because he also went on to say "I thought one of golang's selling points was the fact that it created a simple binary." which relates directly to discussions people make about JIT compiled (eg Python, Javascript, etc) vs AOT compiled (eg C++ and Go). It's also worth noting that you're only specifically discussing environmental variables, where as a development environment is more than just that. Aside having your build tools in PATH (and lets not forget that gcc and make need this just as much as go does), you need supporting shells for the ./config(ure) scripts, any source libraries for C++ includes, and so forth. So you could equally use the same "working [language] environment" terminology to describe C++ - or in fact any other programming language too. Which is why I think he was asking why he needed Go installed to begin with.

fit2rule 11y ago

Thanks, wego is very beautiful and quite useful!

iamcurious 11y ago

Unlike the main post, this is a good use of ASCII art. i.e. to show a drawing/symbol not to make numbers more difficult to parse...

ZenSwordArts 11y ago

Wow thanks for sharing.. this is really is beautiful!

tacticiankerala 11y ago

That's really mind blowing! Thanks for sharing this.