egality_ has quit [Remote host closed the connection]
dviola has quit [Quit: WeeChat 4.2.1]
dviola has joined #ruby
cek has joined #ruby
Vonter has quit [Quit: WeeChat 4.2.1]
Vonter has joined #ruby
reset has quit [Quit: reset]
reset has joined #ruby
rish has joined #ruby
rish has left #ruby [#ruby]
rish has joined #ruby
rish has left #ruby [#ruby]
Starfoxxes has quit [Ping timeout: 264 seconds]
user71 has quit [Remote host closed the connection]
user71 has joined #ruby
cek has quit [Quit: Connection closed for inactivity]
Aminda has quit [Remote host closed the connection]
Aminda has joined #ruby
infinityfye has joined #ruby
rvalue has quit [Ping timeout: 252 seconds]
rvalue has joined #ruby
schne1der has quit [Read error: Connection reset by peer]
<adam12>
henk: One suggestion, looking briefly at your code, is don't rescue Exception. If you want to rescue most relevant exceptions, just call `rescue` bare.
<adam12>
henk: There's a hierarchy of exception classes and Exception is at the top essentially. It includes errors you want want to normally rescue.
<adam12>
(StandardError is the base exception you want, which is default argument to `rescue`)
schne1der has joined #ruby
r3m has quit [Quit: WeeChat 4.2.0-dev]
r3m has joined #ruby
nil78 has quit [Ping timeout: 260 seconds]
nil78 has joined #ruby
<[0x1eef_]>
I kinda agree. I don't think StandardError covers everything you might be interested in, but it is what's often recommended. It's worth checking 'Exception.subclasses', and then decide based on that.
<henk>
adam12, [0x1eef_]: yeah, some linter or something is giving me that advice as well. I have not cleaned that up yet. thank you!
<[0x1eef_]>
Well. The rubocop defaults are a bit extreme for me. :) If you're creating your own error classes, then subclassing from RuntimeError or StandardError is recommended. Still, you don't know other libraries will do that. Checking 'Exception.subclasses' will let you know if that's the case. You might want to handle SIGINT especially too. Same for the others there.
<weaksauc_>
close enough for most intents and purposes though
<henk>
my plan was basically "get it to work" and then "tidy it up", and for exception rescuing in particular: only catch specific exceptions, no generalized catching. so I’m about to go through my all `rescue` statements and make them specific, next.
<[0x1eef_]>
It can be hard to get that right sometimes. For example, SystemCallError is the parent of various Errno exceptions. It's usually easier to use SystemCallError vs know every errno that could occur.
<henk>
yes, that sounds reasonable. I’ll remember that
<henk>
I get a lot of feedback from my linter about `Layout/SpaceInsideParens: Space inside parentheses detected.` because I write things like `config.dig( 'domains', domain, 'tsig_key' )`. I just think it’s friendlier to read than `config.dig('domains',domain,'tsig_key')`. any opinions on that? or even facts to consider?
<weaksauc_>
the last space is an issue henk
<weaksauc_>
first and last i think config.dig('domains', domain, 'tsig_key')
<weaksauc_>
that should pass the lint
<henk>
weaksauc_: oh, yes, right. I guess I can live with `config.dig('domains', domain, 'tsig_key')`. still good enough to read, though I would prefer with those spaces … but less than having to tell the linter to ignore that :D
<henk>
is there an actual issue with the spaces around () or did you just mean "these ones cause that message"?
<weaksauc_>
they just cause the message
<weaksauc_>
but also if all the code you read is formatted like most ruby is you will have an easier time
<[0x1eef_]>
I don't think so. rubocop goes far and beyond what's strictly neccessary.
<henk>
for most parts where it complains about this it’s fine. I just think some constructs are really ugly, like this one: `File.symlink?(File.dirname(cert_file) + "/current.crt")` IMHO it would benefit of some more whitespace …
<[0x1eef_]>
rubocop wants there to be one way and one only, it is essentially the opposite of Ruby in that regard, so it will complain for any style that diverges even slightly.
<[0x1eef_]>
Check out standardrb. It still uses rubocop, but isn't as overbearing.
<weaksauc_>
or the default linter rules that come in rails
<weaksauc_>
downside to standard is that if you really don't like something you can't change it
<henk>
TBH: I’m a bit of a snob. and lazy. meaning: I tend to not use stuff that’s not packaged in debian (: and standardrb does not seem to be.
<weaksauc_>
ah yeah that's right you can do that eh?
user71 has quit [Quit: Leaving]
<[0x1eef_]>
Yep. I don't think you can use the standard executable afterwards though, not sure. I never tried.
<weaksauc_>
yeah same liked the idea of it but not the complete lack of control so that is a nice middle ground that i'll probably try out
<henk>
http://pastie.org/p/7cQAlBqZUwPwrmFOeiuE63 rubocop (I guess) complains that this method is too long. and that the 'return' is redundant. I don’t see a way to make it much shorter. other than leaving out the 'return'. I think being explicit about what is returned helps reading the code and also preventing issues when I add code in this function. what do you think?
Starfoxxes has joined #ruby
schne1der has quit [Read error: Connection reset by peer]
<[0x1eef_]>
No need to assign config since it is never used.
<henk>
huh … so as long as I’m in any code block (i.e. not in the 'main' script) I can just `rescue`?
<adam12>
henk: Yes with newer versions of Ruby (I don't remember which but maybe 2.6?)
<henk>
ok, cool
<henk>
[0x1eef_]: disable specific rubocops: yes, will do that, thanks
schne1der has joined #ruby
<[0x1eef_]>
+1
<henk>
adam12, [0x1eef_]: well, I know I _can_ drop the `return` and if I do, also the assignment to `config`, but I think it’s better to read code that has explicit return statements, especially when what is returned is not simply the last line in the method, as in this case. it takes more cognitive load to process this method and understand that the result of `YAML.load_file` is being returned without
<henk>
the assignment and `return` statement than with it. as it’s now even an untrained eye can guess that the method will return whatever is in `config` and then quickly see that `config` is the content of some yaml file. no need to really process the lines with the rescue and to consider whether they could be the last statement.
<henk>
also, without the `return config`: should I modify that function and add something else, I would have to take care whether that changes what is implicitly returned. with the explicit return, it’s harder to make a mistake.
<[0x1eef_]>
Yeah that's fair, it's your code after all. Typically explicit returns are for early returns or guards - that's a common ruby idiom.
<henk>
but I’m a programming/ruby noob. I’d love to hear the opinions of more experienced people on my thoughts (:
<weaksauc_>
you can add the return higher
<weaksauc_>
instead of at the end
<weaksauc_>
and read_config should be the hint that you are getting a config back
<henk>
hrm, ok, written like http://pastie.org/p/3hNeOgORkbQNwlEBkLxIOb, i.e. with the `rescue` indented to the same level as the `def` and `end`, moving the return value is not as "what? ewww, no!" as I thought. and then it also seems a lot more natural to leave out the `return`.
donofrio has quit [Ping timeout: 255 seconds]
<henk>
thanks, that was very enlightening!
<adam12>
henk: LGTM
<weaksauc_>
yeah same
<adam12>
I might be inclined to capture the exception to a local and not use a global
<[0x1eef_]>
Interesting how that's done. Via alias.
<adam12>
That _is_ interesting.
<adam12>
I've never noticed.
<adam12>
It annoys me that `ri` has no knowledge of `alias`
* adam12
adds it to his list of annoyances
<henk>
adam12: any reason for capturing the exception to a local?
<adam12>
henk: I just don't normally like working with globals, and it makes it more explicit.
<adam12>
> You can also use alias to alias global variables:
<adam12>
Neat.
<henk>
hm, yeah, it is more explicit. but also gets very repetitive and old after a while, I’d guess. just having to always write the same `=> ex` … OTOH all in all it’s about as much to type as using that global and it’s clearer when reading.
<henk>
I guess I’ll do that, as well. thanks
<adam12>
I'm also allergic to the $ symbol O_O
<henk>
hehe
_ht has quit [Remote host closed the connection]
donofrio has joined #ruby
jenrzzz_ has joined #ruby
<henk>
where is the official docs for `rescue` and related words?
ruby[bot] has quit [Remote host closed the connection]
ruby[bot] has joined #ruby
<rapha>
hi all!
<rapha>
for a little thing for our home network, to show the average ppp0 throughput for the current day, which framework would y'all wanna give a shot? (i don't want to use Rails because that's what i have to do at work all day long)
<weaksauc_>
roda maybe?
<rapha>
roda is also on the list of active and well-maintained ones on ruby-toolbox
<rapha>
they also list Hanami, Padrino, Rack-App (which seems reeeeally minimalist, which has some appeal), Goliath and Camping
<rapha>
never heard of any of them
<rapha>
wait, isn't roda maintained by someone in here? adam12, is that yours?
<weaksauc_>
i think he just likes using it
<weaksauc_>
jermey evans maintains it iirc
<weaksauc_>
who also makes sequel
<rapha>
oh, he used to hang out here, too, a long long time ago
<rapha>
and who doesn't like Sequel
<rapha>
i wonder if any of these has Hotwire/Turbo support. that'd be an interesting combo, like, outside of Rails (and i've not yet used it, too)
<rapha>
hah! there's roda-turbo, weaksauc_!
<rapha>
by the way, what happened to your e?
<weaksauc_>
i dq'd and haven't renicked
<rapha>
bummer
weaksauc_ is now known as weaksauce
<rapha>
:D
<rapha>
\o/
<weaksauce>
:D
jenrzzz_ has quit [Ping timeout: 268 seconds]
CRISPR has joined #ruby
jenrzzz_ has joined #ruby
<adam12>
rapha: Roda or Sinatra would both probably be fine.
<adam12>
rapha: I don't maintain Roda tho I am the author of a few plugins for it. I don't use it on new projects, instead trying to build out my own "framework". Going from Roda, I miss small, focused classes.
<adam12>
rapha: For frontend, skys the limit. I'm partial to Unpoly. You could get pretty far with an `<div up-poll="5_000"><render your graph here></div>`.
<rapha>
adam12: currently googling around for the "render your graph here" bit. not wanting to do it with anything that's not self-hosted (in this case, on a little apu2c4 in our basement). with graphs, "cloud"-based seems to be all the rage.
<rapha>
oh right, so i do remember correctly that you have your own framewor
<adam12>
rapha: On my monitoring platform, I used C3.js. It worked well enough. It's a wrapper around D3.js (which requires a PhD to understand)
<rapha>
yes, i tried to help a buddy with D3 before
<adam12>
I use Unpoly in that project as well.
<rapha>
for his Master's thesis in compsci
<rapha>
lest to say we both almost ended up on a psychiatric ward
* rapha
checks out Unpoly
<adam12>
I think there might be better options now, but C3 worked for me. I'd look around if I was doing it again, but my taste is much more refined.
<adam12>
You could use HTMX too.
<rapha>
oh, i've checked out unpoly before. i think it was because you'd mentioned it :P
<adam12>
Or anything really.
<adam12>
Probably. I'm a big Unpoly fanboi
<rapha>
yeah, "anything really" opens the field of possibilities up a little too wide
<adam12>
Could make it a web component with like 5 lines of JS.
<adam12>
setInterval, fetch, etc.
<rapha>
i think i want to stick to hotwire/turbo as that's what my colleagues at work are using who are doing the more frontend-y things and it is how i'd imagined the web will develop, back in 2008-ish, when we still didn't now about that gigantic deluge of javascript that was to follow
<adam12>
I'm sure turbo is fine. Unpoly predates current turbo, back when turbo was less great.
<adam12>
Unpoly is more batteries-included. Modals, layers, etc. all built in.
<rapha>
oh i see
<adam12>
Anyways, I'm going to shut up about Unpoly before someone wants to rename this to #unpoly :P
<rapha>
still don't even understand the difference between hotwire and turbo. i think hotwire is what let's turbo use websockets, or something.
<rapha>
lets.
<rapha>
lol no worries adam12 ... not a lot of tech support happening atm anyhow
<rapha>
man, C3 *does* actually seem to make it possible to use D3. thanks for mentioning that!!
<weaksauce>
hotwire is the complete thing i think
<rapha>
the way one would imagine a graphing library were to work.
<weaksauce>
it includes turbo, stimulus
<weaksauce>
and strada
<rapha>
hmm, the domain _is_ called hotwired.dev. not turboed.dev.
<rapha>
and "The heart of Hotwire is Turbo"
<rapha>
i'll try with rack-app first. it's so minimalist, it probably means i'll have the most in-depth learning to do about the other components of my little stack.
<rapha>
first step, get a dev environment installed on alpine linux running on this little here thing https://www.pcengines.ch/pic/apu2c4_1.jpg (which *i* am a little fanboi about btw adam12 :) )
<adam12>
rapha: Nice. They've closed up shop haven't they?
<adam12>
bbl.
<rapha>
huh? no, i don't think/hope so!
<rapha>
website looks well and alive (and as barebones as ever)
<rapha>
OH!!! "After a long production run, AMD will accept last orders for the SOC used in our apu2/3/4/5/6 boards by end of June 2023."