<cored>
snusnu: I will add the PR so we can debug it together, do you have time?
<mbj>
jo
<mbj>
I'm working. But keeping IRC open to see what happens here.
<cored>
mbj: I thought that you work was OSS :-P
<cored>
flay task do a first check on the specified files but when it's try again with the threshold then it's blows up, at least from rspec point of view
<cored>
something regarding execution expired
<snusnu>
cored: please push the PR yeah, i won't have a lot of time, but i can do a quick pass over it
<cored>
oki
<mbj>
cored: I had payed OSS work, but that was month ago.
<snusnu>
cored: that extraction looks just like what i would've done in a first step .. i probably wouldn't unit test it with actually calling flay tho .. but refactor it so that Flay itself would be injected probably
<cored>
snusnu: I see
<snusnu>
cored: what specific problems are you seeing? cause i assume that anything wrt rspec failing at this point, is no biggie .. as eventually, unit tests should be real unit tests anyway
<cored>
wrt ?
<snusnu>
with respect to
<cored>
oh ok
<cored>
well that weird error regarding execution expired
<cored>
I'm guessing that probably that's better to do is making the call from rake
<cored>
for testing
<snusnu>
oh well, i know where that comes from i guess .. we add a unit test timeout ourselves .. and actually calling flay surely takes longer than what we allow for unit tests, since, well, a proper unit test would probably never call flay .. that'd be an integration tet
<cored>
sure thing
<cored>
I normally start with an integration test to know how all the pieces work
<snusnu>
good plan
<cored>
and then start to extract things into more smaller pieces
<snusnu>
i do that too
<cored>
so, which is your suggestion to keep moving this forward ?
<snusnu>
so as a starter, you could probably just move your current test to spec/integration .. and if my assumption was right, the expired execution should go away
<snusnu>
devtools automatically adds the unit test timeout to all specs in spec/unit .. but not for spec/integration
<cored>
let me check
<cored>
yeap
<cored>
you were right
<cored>
so we are green now
<snusnu>
sweet
<cored>
I just need to have a better assertion
<cored>
this method just do stuffs, but it doesn't say anything about if it have failed or succeded
<snusnu>
you could probably start with thinking about what Task::Flay.call should return .. imo, it could return self
<snusnu>
right, it could also return some sort of Result#success? .. but tbh, i'm not sure at this point .. i'd suggest breaking it into pieces a bit, do the "typical" refactoring stuff .. more objects/methods will pop up, and you will get a better picture
<cored>
snusnu: sure thing
<cored>
snusnu: will work on that, then
<cored>
;-)
<cored>
thanks for the suggestions
<snusnu>
heh cool, one thing coming to mind is to have some "nested" runner object .. i'm thinking this, because actually we're invoking flay twice … maybe the return of that, could indicate success .. but again, i'm not sure … i'd have to dive deeper but i don't have the time right now
<snusnu>
you'll figure something out tho, i'm sure ;)
<snusnu>
thx for taking the time!
<cored>
no proble
<cored>
this looks like will be fun and I'm also starting to learn some stuffs about rom-rb internals like the execution stuff ;-)
kleech has joined #rom-rb
<mbj>
snusnu: I think we should have environments in substation that carry request specific data. Such as a response object.
<mbj>
snusnu: response object as in Sinatra.
<snusnu>
mbj: not sure i follow?
<mbj>
snusnu: What if there is a transient object that must be accessible for all stages of a substation chain
<mbj>
snusnu: how to inject it?
<mbj>
snusnu: So I'll reuse the dispatcher, but create a new env each request.
<mbj>
snusnu: Because the request is accessbile for all stages of a chain.
<mbj>
snusnu: No code change needed.
<snusnu>
mbj: ah, the service registry we were talking about .. yeah, i'm all for that, but that's probably best implemented in the application environment itself
<mbj>
snusnu: We are talking about the same ;)
<snusnu>
mbj: actually, i want to change substation so that it doesn't require any specific Request class .. just a few methods on something it can use as a request
<snusnu>
mbj: that object, the application specific request object, will then be free to provide it's application environment
<mbj>
jo
<snusnu>
mbj: which in turn will be free to provide some sort of service registry
<mbj>
I'll have to give my app a refactoring round. Because I rely on some hacky side channels to overcome some sustation limitations like this.
<mbj>
Also I'm on an old substation version ;)
<snusnu>
yeah, currently i only access *one* singleton instance … the router, but there could be more maybe
<snusnu>
i need to have the router available in the app env, do provide the #url method to view classes
<snusnu>
i don't like how i currently access the router singleton instance for that, from my env, so yeah, this would be a candidate service for registering with the app env
<snusnu>
please upgrade .. :)
<snusnu>
all this might require moving things around a bit .. i'm not sure wether the current "building phase" supports having an immutable app env object, that already has all required services registered
<mbj>
yeah
<snusnu>
my way of things is to wait for another candidate service to pop up, before i start this refactoring myself tho
<mbj>
I like to remove all my singleton instances in my app to a minimum.
<snusnu>
same goes for the "independent" request object … i'm fine for now with wrapping my app specific request object in a Substation::Request .. it will be easy to switch out once substation is refactored
<snusnu>
me too, but i have more urgent things on my plate now :)
<mbj>
yeah
<mbj>
Same here ;)
<snusnu>
heh, thought so
<snusnu>
but btw, oh, forget it .. you *must* use sinatra iirc
<snusnu>
(cause really, substation on plain rack with http_router is awesome enough ;)
<snusnu>
another feature for a next substation release will be the "split" processor i mentioned recently
<snusnu>
i'm thinking of having it so that you can register n chains with this processor, and have a way for the processor to ask every chain, given some input, if it can process the input
<snusnu>
very useful for content type negotiation on the incoming side .. plus response generation on the outgoing side
<mbj>
snusnu: Yeah, I *must* use sinatra ;)
<mbj>
snusnu: Lots of "ugly" stuff gets cleanup up with exposing Environment#http_{request,response} in my substation chains.
<mbj>
snusnu: For layer wrapping, I'll have an "outer" Environment with http information, and an inner Environment without ;)
<snusnu>
mbj: i'd be interested in having a look at how you ended up doing things .. if that's possible at some point
<mbj>
snusnu: No need for handling that stuff for myself, but thx.
<snusnu>
mbj: fair enough
<snusnu>
mbj: btw, whenever i offer something, i'm open to suggestions too :p
knowtheory has quit [Quit: Computer has gone to sleep]
kleech has quit [Remote host closed the connection]
knowtheory has joined #rom-rb
<mbj>
snusnu: I'm just busy. It feels hard to be away from OSS that much ;)
cored has joined #rom-rb
cored has joined #rom-rb
snusnu has quit [Quit: Leaving.]
breakingthings has quit []
breakingthings has joined #rom-rb
<cored>
somebody here?
<mbj>
cored: yeah
<cored>
mbj: just wondering about devtools methodology
<mbj>
cored: shoot
<cored>
I'm solving an small problem, after doing a little spike
<cored>
with an integration spec
<cored>
I wonder if it's time to add devtools so it can guide me to a better code base
<cored>
or when exactly do you guys start using it ?
<mbj>
cored: I introduced it to projects in any kind of live cycle.
<mbj>
cored: from greenfield to legacy rails app.s
<cored>
sure
<cored>
this is an small lib
<cored>
I was wondering if you do that after doing the spike
<mbj>
cored: Before a commit, or PR or whenenver I think so, I raise the bar a littlebit let myself think about architectural decisions I did befor.e.
<cored>
also, when do you know you actually finish; at the moment my lib can solve the problem I have but I know that the code is not in a good shape
<mbj>
cored: There is no hard rule, you have to explore it.
<cored>
I see
<mbj>
cored: A valid strategy would be to finish your spike and make it useful. Than let devtools guide you to the refactoring.
<mbj>
*to => through
<cored>
sure thing
<cored>
will do that
<cored>
I'm checking mutant code to learn how you tested the parsing of args
<cored>
from the command line
lgierth has joined #rom-rb
<cored>
I wonder why is this an smell
<cored>
PuzzleSolver::HorizontalWords declares the attribute words (Attribute)
<cored>
how can you access data from a class if you can't expose it
<cored>
?
<cored>
or the smell is related to naming the accessor with the same name as the instance variable
<lgierth>
cored: i think exposing state through accessors is considered a smell if you don't have a good reason for it
<lgierth>
so the question this poses is whether this state should be exposed at all
<cored>
hm
<mbj>
lgierth: You had a mutant question days ago?
<cored>
lgierth: I see
<mbj>
cored: The idea is that the public interface of your class becomes minimal.
<mbj>
cored: As more "narrow" your public interface is, the better the chance you have good code/mutation-coverage/bugs-per-public-inteface ;)
<lgierth>
mbj: i did, but as you said i should have written it down. give me a moment :)
<mbj>
lgierth: You can search the logs of this channel. irclog.whitequark.{org,com} (donno remember tld)
<lgierth>
oh right. it's about testing mutations for a node that can't live on its own
<lgierth>
e.g. for resbody in this case
<lgierth>
i can't test it in isolation, only together with a rescue node
<lgierth>
but admittedly i haven't looked for other similar nodes yet
dkubb has joined #rom-rb
<mbj>
dkubb: hola
<lgierth>
mbj: i'll get back to it over the weekend
<mbj>
lgierth: You are extracting a generic mutator?
<mbj>
lgierth: better, you are extracting a node out of the generic mutator.
<mbj>
lgierth: ?
<lgierth>
yeah the resbody node
<dkubb>
good morning
<dkubb>
er afternoon
<mbj>
lgierth: In this case you add an example for the "nest possible parent" mutator. And cover it from here.
<lgierth>
ah, cool
<lgierth>
thanks, i'll give that a try
<mbj>
lgierth: So for resbody I'd choose an example in rescue mutator spec.
<mbj>
*if exist
<mbj>
Mutants self coverage is not perfect ;)
<mbj>
dkubb: hehe
<lgierth>
:)
<mbj>
lgierth: Testing the mutation tester is hard, the zombie (the dynamically created in-memory deeply dependency vendored mutant), that is able to self test mutant just became stable.
<mbj>
dkubb: Getting "sick" of rspec syntax.
<mbj>
dkubb: I need something like an LSP aware unit test framework.
<mbj>
dkubb: Where I can easily share invariants/boilerplate across implementations.
<cored>
mbj: got it
<cored>
I think I found a bug in devtools
<cored>
if you run rake metrics:flay I get an error regarding a .sum method
<cored>
dkubb: I think we were talking about this the other day
<cored>
maybe after the extraction that I'm doing it would get fix
<cored>
I have a lot of smells, according to reek
<mbj>
cored: reek is not a definitive authority
<dkubb>
what I would suggest with reek is to try to understand why it flagged a specific smell, and then decide if it's right before ignoring it in the config
<mbj>
cored: I typically whitelist some stuff I personally dont identify as smell.
<mbj>
cored: So reek and any other devtools tool is making you notice you code improved / declined in quality.
<mbj>
dkubb: I'm thinking about adding "subject capture excpressions" to rspec metadata.
<mbj>
dkubb: So a spec can declare it kills mutants on a specific subject.
<dkubb>
tools like reek probably can't be too precise without missing lots
<mbj>
dkubb: This way stuff like the sql emitter / unparser can be speced efficiently. And also we overcome the "private logic in parent needs to be covered from child public interface" situartion.
<dkubb>
mbj: interesting. would it allow rspec to skip over some stuff
breakingthings has quit []
<mbj>
dkubb: Also yea.
breakingthings has joined #rom-rb
<mbj>
dkubb: See dkubb/sql emitter, a single public interface for unparsing all sql.
<mbj>
dkubb: So mutation covering this would be horror.
<mbj>
dkubb: But with "inverse subject capturing metadata" you can declare a specific context (the rspec one) covers a specific emitter.
<cored>
I see
<cored>
neat removed the attribute
<cored>
made the object to say what is doing inside with the data instead
<cored>
I notice something now, this objects are not doing that much so it is safe to just drop it's specs
<mbj>
cored: ?
<mbj>
cored: You can also use private attr readers ;)
<mbj>
def initialize
<mbj>
@foo = expression
<mbj>
end
<mbj>
attr_reader :foo
<mbj>
private :foo
<mbj>
(making it private after attr reader specified)
<mbj>
reek does not "know" this.
<mbj>
Or use the private keyword and use attr_reader afterwards. (Dont think reek understands this)
<cored>
oh
<cored>
nice
<cored>
did not know that, thanks
<cored>
I almost remove all the code smells
<cored>
I just have a nested iterator left
<mbj>
cored: Some of them are acceptable
<mbj>
cored: But maybe you can just move the inner iteration, or use some of the Enumerable api to avoid it?
<cored>
mbj: thinking
knowtheory has quit [Ping timeout: 252 seconds]
knowtheory has joined #rom-rb
cored has quit [Ping timeout: 240 seconds]
<dkubb>
mbj: I think when people are getting used to reek it's better to tell people to follow it stuff, and only if you really disagree to bring it up with one of us.. sometimes it takes a bit to get a feel for when the tool is wrong or not by actually working with it and seeing if your code improves overall or not
cored has joined #rom-rb
cored has joined #rom-rb
<dkubb>
mbj: I would say many times I've disagreed with reek, then made it happy anyway, and the end result was better than I would've predicted. sometimes not too, but you can't always know what it'll be like until you've used it for a while
<cored>
mbj: it is possible to set optionparser to parse the argument lists withut specifiying any option
<cored>
like example.rb filename filename
<cored>
I just see examples like example.rb --option