jgaskins has quit [Quit: This computer has gone to sleep]
_jesse__ has quit [Ping timeout: 252 seconds]
lgierth has joined #rom-rb
<dkubb>
lgierth: so you saw a new failure in mutant?
<dkubb>
my noops for a few new pieces of code I wrote just started failing
<lgierth>
yeah had a quick glance and then it ran away
<dkubb>
even though the specs pass
<lgierth>
what is a noop, anyway?
<dkubb>
the noop is like a kind of self test for mutant
<dkubb>
what it does is parses the code, then generates code without any mutations. then it runs the specs with this code
<dkubb>
it's expected that the tests should pass in this case
<dkubb>
if they don't, then it means that unparser has a bug (or parser)
<lgierth>
would be good to print the original error then :)
<dkubb>
yeah, I was going to ask mbj about that
<dkubb>
when rspec fails in this case it would be really helpful to get the actual spec failure output
<lgierth>
if it's reproducible it's fine, but it's hard to hunt the heisen specs
<dkubb>
I was just debugging this locally and I was going to do it myself
<dkubb>
maybe I can patch mutant itself to do this
<dkubb>
lgierth: so what's hatetepe?
<lgierth>
let me know when you have something, then i'll add it to hatetepe as well
<lgierth>
a long time ago i was annoyed with the inconsistent apis of http client libraries, and eventmachine + fibers was cool :)
<lgierth>
and when i quit my job in july, i picked it up again, to get familiar with the tools again, and to re-adjust to working on my own stuff
<lgierth>
and to make it a proper project
<lgierth>
and i finally found out that apart from tinkering, i'm actually solving a problem
<dkubb>
lgierth: does it rely on any lower level apis, or does it use the em socket stuff directly?
<lgierth>
eventmachine and fibers
<dkubb>
it's good to have side projects like tis
<dkubb>
s/tis/this/
<lgierth>
but i'm planning to add a celluloid-io backend
<dkubb>
ahh ok, I was curious about that
<lgierth>
the problem i'm solving is finally an http client lib with readable, well-tested code :)
<lgierth>
btw, everything i said with 'http client lib', applies to http server lib as well
<dkubb>
hehe
<lgierth>
it can do both
<dkubb>
it's funny how many libs there are, yet how much the quality is all over the map
<lgierth>
the nice thing about it being a server AND client, is that the integration specs are completely self-hosted, i.e. server and client in one reactor
<dkubb>
does your lib handle requests and responses as "streams" .. by that I mean, does it allow me to construct the request url, headers, and then dynamically stream input for the message body? same thing with reading, can I stream the response and hand it off to thinks like sax-like parsers?
<lgierth>
and that i can use the handler mechanism (something like hooks or plugins) to spy into what's going on at different levels
<lgierth>
that same mechanism also decouples the server core and client core on the one hand, from non-core-protocol things like keepalive, semantic details, etc.
<lgierth>
dkubb: yes
<lgierth>
your code gets the request/response as soon as the headers have been parser, i.e. HTTP::Parser.on_headers_complete
<dkubb>
nice
<dkubb>
a pet peeve of mine is when a framework assumes that the requests and responses should always be buffered
<lgierth>
request.body is an IO duck that blocks for the fulfillment of the 'closed' promise
<lgierth>
yeah it's too much of an assumptiom, and such an unneccessary one
<lgierth>
for the streaming part, you can use the promise' progress mechanism to get chunks as they come in. or use #each for the same effect, except that it blocks
<dkubb>
ahh nice
<lgierth>
progress was actually dropped in promises/a+, but i found it a nice and simple feature
<lgierth>
blocking means, that the fiber suspends and gets resumed on fuifillment or rejection
<lgierth>
so yeah and right now i'm sitting down and killing mutatios
<dkubb>
heh
<lgierth>
takes a lot of dicipline to actually make `rake ci:metrics` or `rake ci` your build script
<lgierth>
but i found it to be extremely rewarding
<lgierth>
and yielding immediate result, every time
<dkubb>
yeah, it's difficult, but I think it makes a big difference in the resulting code
<dkubb>
and it sticks with you through more than just the lib you do it with. it affects all the code you write
<lgierth>
for applications it's arguable if it's sustainable, or even worth the time
<dkubb>
when a lib flags my code what I try to do is not just dismiss it right away, I like to try to figure out the thought process that the author was going through when he decided to write the rule
<lgierth>
but for libraries it makes so much sense
<lgierth>
exactly, it sticks with
<dkubb>
I do it on one application, it's much easier to keep going
<dkubb>
if you do it from the start it's not so bad. it would be hard to add though
<lgierth>
yeah i can only relate to 'add later' for now...
<lgierth>
i didn't try adding devtools to anything existing yet, but i imagined it
<lgierth>
i used to work on soundcloud's rails mothership for 1.5 years
<dkubb>
ahh yeah, it would be hard the bigger the team too
<lgierth>
true
<dkubb>
because there'd always be that one developer who ignores stuff or constantly fights against it
<dkubb>
my belief is I want it done on any projects I have to maintain myself
<lgierth>
tools and (more importantly) methodology itself, were easier to change and adapter in the small teams, that later emerged around projects we pulled out into services
<lgierth>
i wanna try it with a new application
<lgierth>
but right now i'm trying something else, and i don't wanna mix experiments
<lgierth>
outside-in testing and clean architecture. i basically start with a cucumber story, then implement the steps, and the interactor class to back it
<lgierth>
that part is fore getting a sense of the requirements. does my initial idea actually make sense? the story will also quickly grow, so i'm constantly forced to cut the requirements to the bare minimum
<lgierth>
then i use the same story for acceptance tests
<dkubb>
interesting
vsorlov has joined #rom-rb
<dkubb>
you throw away the cucumber stuff and write the acceptance test with rspec?
<lgierth>
no, the cucumber story drives both the interactor integration tests, and the acceptance tests
<lgierth>
via cucumber, backed by rspec-expectations
<lgierth>
but i'm not happy with that
<lgierth>
i like that the cucumber story drives both, because i find the coupling to be a valuable constraint
<lgierth>
but the implementation of the steps is a bit uncomfortable, i'm more used to rspec
<lgierth>
very heavy, but always does what i expect
<lgierth>
(rspec, that is)
<lgierth>
hehe i just noticed that i didn't even read that book i linked in openposting's readme
<lgierth>
uncle bob
<dkubb>
I haven't read that one either
<lgierth>
could i ask you something regarding unit spec subjects?
<dkubb>
sure
<lgierth>
i have these classes that are more state machine than immutable
<lgierth>
and my interpretation of the subject in this case is, that it bring the object into a certain known state, the run the subject code, and then in the example itself, everything has happened, and i make assertion about the state of the object, and interactions with other objects
<lgierth>
so it's basically before; subject!; specify
<lgierth>
do you see anything obviously bad about that?
<lgierth>
i'm somehow thinking it makes my specs more BDDish
<dkubb>
there's two schools of thought on what the subject should be in a sepc
<dkubb>
*spec
<dkubb>
the classic one is that the subject is the object under test
<lgierth>
being able to verify message expectations only after the fact, also makes me build big walls of doubles and allow(a).to receive, but that makes it very explicit what the object's dependencies are
<dkubb>
the one we use in some ROM style unit tests is that the subject is the message sent to the object under test
<lgierth>
i think i've noticed these double walls in rom-* as well :)
<dkubb>
yeah, I generally do try to minimize those
<dkubb>
one of the things I do is only try to use doubles for objects that change state
<dkubb>
for a value object or an immutable object, you can usually use the real object in the spec
<dkubb>
a value object is immutable of course, but it has the extra property of being a kind of "richer primitive" object
<lgierth>
i'm only using them for certain things as well, not sure what my rule is based on, but in hatetepe i don't exchange Request, Response, and Promise for doubles
<dkubb>
that's probably good, I assume those are all immutable once initialized?
<lgierth>
my rule might be something like, "is a general code mechanism"
<lgierth>
mmh no
<lgierth>
i'd like them to, but i haven't figured it out yet wrt to streaming
<lgierth>
promises can't be immutable, since they're an fsm
<lgierth>
(from what i understand, i'm relatively new to the concept of immutable state)