<mbj>
But I compiled ruby for myself (ruby-install).
zekefast has joined #rom-rb
zekefast has quit [Quit: Leaving.]
snusnu has joined #rom-rb
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
zekefast has joined #rom-rb
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
<snusnu>
yo mbj
knowtheory has quit [Quit: Computer has gone to sleep]
<mbj>
snusnu: hola
<snusnu>
mbj: i have local substation code that supports to define failure chains like this: http://pastie.org/8121008
<snusnu>
mbj: any comments?
<snusnu>
mbj: the goal was to be able to compose "raw" web actions, and then support building on top of those, only with different failure chains
<snusnu>
mbj: think, some web action, for html, render it, for json, serialize it
<snusnu>
mbj: in failure case i mean
<mbj>
snusnu: TBH no time :D
<snusnu>
mbj: hehe, ok
<mbj>
snusnu: For thinking that deep, but I'm using substation currently so maybe it makes sense in an hour.
<snusnu>
mbj: just keep in mind how you'd want to construct failure chains, and how you'd like to "inherit" those from some common "web action", that needs to either return HTML or JSON
<mbj>
snusnu: okay, plugging them together.
<snusnu>
mbj: i want to design my apps so that i have a raw App::Action, then some Web::Action that e.g. sticks sanitization in front, and then build some Web::{HTML, JSON}::Action on top, that simply "alters" the failure chains of the Web::Action it builds on top of
<snusnu>
mbj: my current code supports that
<mbj>
snusnu: I dont get it 100%, dont have an image now.
<mbj>
snusnu: Lemme work more ;)
<snusnu>
mbj: ok :)
<snusnu>
mbj: but let the pastie sink for a minute or so :D
<mbj>
snusnu: later busy. Will ping you soon!
postmodern has quit [Quit: Leaving]
<mbj>
snusnu: I trust you abut it improves, but I need to do sth else before :D
<snusnu>
mbj: no worries :)
<snusnu>
mbj: i will go change shitloads of specs in the meantime ;)
<mbj>
snusnu: I get bid by some tool beeing clever for F5 driven development to often!
<mbj>
snusnu: I'm doing a short break from commercial stuff, skype followup?
<mbj>
Finally meet faces?
dkubb has joined #rom-rb
<mbj>
dkubb: morning
<snusnu>
mbj: hey, sorry, right now is a bad time for skype, maybe later today evening .. but, if you're taking a break, i just pushed the fully mutation covered failure chain enhancements
<snusnu>
:)
<dkubb>
good morning
<dkubb>
mbj: is there a way to selectively disable a mutation that can't be killed? I have a private method declaring permitted params and mutant is adding nil to an Array passed into that method.. I don't think I can kill it without stubbing rails' strong parameters, and given that all this logic happens in a private method I'd rather not do this. I have other test that make sure the strong params config works
<mbj>
dkubb: I think we should remove that mutation.
<mbj>
dkubb: Lets focus on universally killable mutation. We have enough of them.
<dkubb>
mbj: ok. yeah, that mutation is hard to kill sometimes
<dkubb>
mbj: sometimes the only way to kill it is to mock out the other dependency
<mbj>
dkubb: And yeah there was a --blacklist switch in 0.2
<mbj>
nope there wasnt
<dkubb>
mbj: heh, yeah I didn't see anything in --help so I wondered if it was there
<mbj>
dkubb: I have some filtering infrastructure in the code. Have to check later, should be easy to add such a feature.
<mbj>
dkubb: BTW I plan to add a YAML loader for the configuration. This will allow us to directly read the mutant.yml
<mbj>
dkubb: If you need a beta release for ease of use, ping me. Can do it now.
kapowaz has quit [Ping timeout: 245 seconds]
<dkubb>
mbj: that would be awesome
<dkubb>
mbj: you'll probably notice a bit of activity on my side wrt mutant and devtools, it's because I'm working on a rails app and trying to feed back what I'm learning into the project
<dkubb>
mbj: right now we need axiom-memory-adapter the most from me, but because I'm working with this stuff for most of my working day I'm able to contribute a bit more on that side
<mbj>
dkubb: aweseome, mom
<mbj>
dkubb: pushed mutant-0.3.0.beta13
<dkubb>
cool, thanks
<dkubb>
mbj: I can update devtools. I'm going to merge that rubocop branch in too in a sec
<mbj>
mutant just cracked 20k downloads.
<mbj>
dkubb: thx
<mbj>
It seems it is in use outside our community/project!
<snusnu>
dkubb: and i do know where to look for config settings now, so, win :)
<dkubb>
snusnu: we can decide which convention we disagree with and update the defaults in devtools
<dkubb>
snusnu: also, right now rubocop is advisory only.. the build won't fail if there are offences. that's because there's no way to selectively disable them on a per-class/method/file basis
<dkubb>
snusnu: I hate it when metrics tools don't provide this kind of selectivity. it's common that there's a convention you want to follow *most* of the time, except for one place.. and I hate it when you have to disable it globally
<dkubb>
like for example, I generally follow the 79 chars per line rule, except in DSL code like in DM property definitions
<snusnu>
dkubb: yeah, agreed
<snusnu>
dkubb: btw, is there a way to not check the number of method params at all? reek checks that already, and it supports selective disabling
<dkubb>
snusnu: one of the really neat things is guard-rubocop
<dkubb>
snusnu: does it have to be a Symbol? how are you using handler?
<snusnu>
dkubb: well, i never got into the guard workflow, my notebook is old, and i hate it when it turns loud because of the fan .. also, i do :w WAY TOO OFTEN for that :)
<dkubb>
ahh I see
<snusnu>
dkubb: for that case, it needn't be a symbol, i could just turn it into a string
<dkubb>
snusnu: yeah, I would probably use a string for that, rubocop warning or not
<snusnu>
dkubb: right
<snusnu>
omg, there we go: Avoid using {...} for multi-line blocks.
<snusnu>
hehe
<snusnu>
mbj, dkubb: ^^
<dkubb>
hehe
<dkubb>
fwiw, I generally do try to avoid multiline blocks using { and } .. I also try to avoid chaining onto a multiline block
<dkubb>
but when I do have method chaining I still use { and } because I think writing end.something is weird
<snusnu>
yeah, fwiw, i really like the convention to use {} when the return value is significant … or when the block fits on one line and the return value is not significant
<snusnu>
and what i really can't stand, is let(:foo) do … end
<snusnu>
i guess i need to disable that sucker
<dkubb>
I don't mind let do/end when it's multiline
<dkubb>
the return value isn't significant in a let() function.. its basically alternate syntax for a memoized define_method
<dbussink>
snusnu: dkubb: probably rbx
<dbussink>
snusnu: if you have a way to reproduce it, that would be great
<dkubb>
snusnu: you could print out whatever parser is parsing before that explosion to see what the code is it's choking on
<mbj>
snusnu: Can you identify the offending file and reduce it?
kapowaz has joined #rom-rb
<snusnu>
mbj: will look at it later … do we actually prefer #reduce over #inject ?
<snusnu>
mbj: imo the name #inject fits better in quite some circumstances .. #reduce somehow has a rather narrow scope, then again, i'm no native english speaker
<snusnu>
mbj: fwiw, substation is rubocop clean now
zekefast has quit [Quit: Leaving.]
<coxandrew>
snusnu: rubocop allows you to selectively disable offences:
<snusnu>
coxandrew: interesting, thx for the headsup! but yeah, i somewhat dislike tool related comments inside the code
<coxandrew>
same here
<snusnu>
coxandrew: tho it might be acceptable inside specs maybe … i'd only need it there anyway, the only violations i still have left are 80col limit, and i don't care about that inside specs
<snusnu>
coxandrew: because i'd still like rubocop to warn me about library code with longer lines than that
<coxandrew>
yep … I only have one override right now and it's in application_helper.rb … which feels like it could be a little dirtier than other classes :)
<snusnu>
hah
<snusnu>
that whole thing is a smell ;)
dkubb has joined #rom-rb
<dkubb>
coxandrew: yeah, I find the idea of litering the code with that kind of stuff icky too. what I would wish for is something like reek's config, where you have an exclude list of specific methods you want to skip testing
<snusnu>
dbussink: if i link you to a failing substation build (again), would that work for you? ;)
<coxandrew>
yeah, it's a junk drawer for us right now … before too long we'll probably move to presenters for most of that stuff
<dbussink>
snusnu: well, is it reproducible?
<dbussink>
snusnu: if you can provide steps to reproduce the problem, we can work with that
<snusnu>
dbussink: travis constantly fails when running rubocop on rbx against substation
<snusnu>
dbussink: so yeah, the steps basically are 1) bundle substation 2) run rake ci
<snusnu>
dkubb: with that change, i cannot make rubocop happy, when i use #find, it wants me to use #detect, when i use #detect, it wants me to use #find :)
<dbussink>
snusnu: can you open an issue with the steps etc.?
<snusnu>
dkubb: my workaround was to remove the CollectionMethods settings provided by devtools' rubocop.yml
<snusnu>
dkubb: thus using rubocop defaults
<dbussink>
snusnu: hmm, just rant it locally against master, seems to work fine
<snusnu>
dbussink: well, even better then, no? ;)
<snusnu>
dbussink: i'll just wait for travis to deploy latest rbx then
<dbussink>
snusnu: hehe, dunno, could you easily check against latest master as well?
<snusnu>
dbussink: that might sound crazy (or lazy for that matter) .. but for some reason i can't compile rbx on my box anymore .. no idea why, no energy to investigate further
<snusnu>
dbussink: fwiw, i'm almost 100% sure this has nothing to do with rbx :)
<dbussink>
sound like maybe a bug we should fix then
<dbussink>
any backtraces etc.?
<snusnu>
dbussink: last time i checked it seemed like i somewhat fucked up my homebrew
<snusnu>
dbussink: i don't have time now, but i will check it again soon and let you knpw
<snusnu>
bbiab
snusnu has quit [Quit: Leaving.]
snusnu1 has joined #rom-rb
snusnu1 has quit [Client Quit]
snusnu1 has joined #rom-rb
knowtheo1y has joined #rom-rb
zekefast has joined #rom-rb
knowtheory has quit [Ping timeout: 268 seconds]
<dkubb>
mbj: I think I may have a way to resolve the issue solnic has with --rspec-dm2 style specs
<mbj>
dkubb: contributions to mutant ahead?
<dkubb>
mbj: the problem right now is that dm2 style specs does make it harder to refactor when you have a ton of specs for methods that have public interfaces
<mbj>
Yeah
<dkubb>
mbj: maybe, I'll see
<mbj>
I know, I'd love to add those kill expressions, but I'm busy with commercial stuff, sorry.
<mbj>
Mutant is far from perfect :D
<dkubb>
mbj: I think if people were to only write specs for @api public methods that should result in the same amount of killed mutants
<dkubb>
mbj: it'd be almost as fast, but it would help with refactoring. you *should* be writing specs that exercise the full public interface of each method; regardless of whether you put them all in a single file per-class or file per-method
<mbj>
dkubb: I get your pont.
<mbj>
I was thinking about loading the whole rspec world, than selecting the specs by description.
<mbj>
So how you strucutre the rspec files is your decision.
<mbj>
But rspec is really nitpicky :D
<dkubb>
mbj: then it becomes simply a matter of organization, how you want to lay out the files.. and it's no longer an issue about specifying things that may change
<dkubb>
mbj: if anyone was to suggest an approach that meant they relied on side-effects of tests on other public methods to cover a public mehtods, I would strongly oppose moving in that direction
<dkubb>
I absolutely loathe relying on incidental coverage
<mbj>
yeah
<mbj>
I have to run now, feel free to resurect some rspec stuff in my very old gists. Maybe you can nuke all spec file layout stuff with that info.
<dkubb>
as soon as you move in that direction imho what you have is an integration test
<mbj>
I see your point, would love to participate and solve it but have to run