<mbj>
snusnu, solnic: Lets have a mutant & coverage & rspec style meeting in skype in the weekend? I'd love to present / validate / discuss my plans I have with mutant.
<snusnu>
mbj: i can probably find time during the weekend, can't exactly promise right now tho, i will know on friday for sure tho
<mbj>
snusnu: nice, I'll ping dan also.
<mbj>
What I plan will take some time of my 3-week-for-oss block, and I need to make sure the idea is not "so dump" ;)
<solnic>
I'm happy with mutant the way it works with my patch
<solnic>
I use it in virtus
<solnic>
also sorry but I don't have time during the weekend
<skade>
mbj: just to register interest: any plan in bringing vanguard forward?
<solnic>
+ I'm pretty much tired, as you know, with tools-related discussions, I just want to write code that works
<solnic>
mbj: the only thing that would make it totally insanely great is that live-coverage tracking thingy you mentioned
<solnic>
line*
<mbj>
skade: yeah I have plans. But no time.
<snusnu>
skade: hey, what are you missing in vanguard?
<skade>
snusnu: documentation and stability. It's really hard to introduce to teams.
<skade>
not complaining, but the last times I tried, we ended up with activemodel validations
<snusnu>
skade: right, i totally agree about the doc part .. i haven't hit stability issues so far, but yeah, the docs need to be improved
<snusnu>
skade: also, i'd love to see some common code towards i18n and stuff ...
<mbj>
snusnu: it needs axiom-types axiom-logic integration
<snusnu>
skade: also, imo vanguard shines best when used in conjunction with ducktrap .. and ducktrap has NO docs :p
<snusnu>
mbj: well, it doesn't need those to work, it works fine already, with axiom-* it's "better factored" that's true
<skade>
ducktrap looks interesting ;)
<snusnu>
skade: ducktrap imo is one of the most awesome pieces mbj did ;)
<snusnu>
mbj: you know how i mean that, wrt mutant :p
<skade>
is it a bit like roar, but more general?
<solnic>
skade: it's a bi-directional mapper, turn input into output and vice-versa
<solnic>
with a very powerful DSL where you can configure how stuff gets converted/transformed/coerced etc
<solnic>
skade: think about virtus that works both ways
<snusnu>
it's a data transformation algebra … you use a declarative dsl to describe the transformations that should occur for the input .. so say you expect a hash of strings and know that this hash can be used to "fill up" a (virtus, anima) model .. you can write transformations (and their inverse) .. so that you can just do YOUR_TRAP.call(some_hash) => SomeObject .. and YOUR_TRAP.inverse.call(some_object) => some_hash
<snusnu>
it's awesome for input data sanitization
<snusnu>
and i suspect that it will be the cornerstone of rom-mapper at some point
<snusnu>
really, it can be used for *a lot* of common stuff
<skade>
okay, so it is an alternative to roar/representable (i am not a huge fan of it, but it has adoption ;) )
<snusnu>
i'm not familiar with those
<solnic>
yes you can say that
<solnic>
but it's probably more flexible/powerful than those two
<snusnu>
skade: it also gives you detailed error tracking .. so if you use a ducktrap for input data sanitization .. it will tell you *exactly* which (deeply nested) hash key failed transformation .. and why
<skade>
my problem with representable is that it does a lot of implicit guessing, which breaks alot of stuff :(
<solnic>
snusnu: I'm not sure we need ducktrap in rom-mapper because it's a different use case, we have schema, we have mapping we have headers, it's obvious how stuff must be converted and there is no sanitization/coercion needed
<snusnu>
skade: so in a web app, i typically receive a json body, deserialize that, run it through a ducktrap, and boom .. i have an input *model* instance
<solnic>
it might change however once we get to support non-sql stuff
<solnic>
think about databases where we actually do need to coerce stuff coming from tuples
<solnic>
I wonder if axiom is supposed to handle that eventually
<snusnu>
solnic: it's not so much about sanitization/coercion .. it's about the fact that ducktrap *is* a mapper already .. it can used to map arbitrarily deep object graphs
<solnic>
because if it does, then again, no need for ductrap in rom-mapper
<snusnu>
solnic: imo we could experiment making rom-mapper use ducktrap under the hood .. rom-mapper providing the nicer ,mapping focused dsl .. but let ducktrap do the dirty work
<solnic>
snusnu: I am more than happy to try out ducktrap
<solnic>
in rom
<solnic>
I've seen your discussion with dkubb about it btw
<solnic>
I like the idea that ROM is basically an interface
<solnic>
where we plug in stuff
<solnic>
it's the same with session btw
<solnic>
we can have a session interface
<solnic>
where we plug in tracker and UoW
<solnic>
this stuff would be amazingly powerful
<snusnu>
yeah, that's the way to go
<solnic>
so, I'm all for that, I don't want you to think I'm against using ducktrap or something
<solnic>
I'm not 100% sure we need such a beast but I agree we COULD use it
<solnic>
beast being something awesome
<snusnu>
skade: for completeness sake, once i received that input model instance (from ducktrap) .. i use vanguard, to perform the actual validations .. this is just to complete the context i use vanguard in
<snusnu>
solnic: hah, right
<snusnu>
solnic: and tbh, i'm not entirely certain either at this point
<snusnu>
solnic: but here's one thing .. i believe that i can use rom-relation without rom-mapper .. simply by having ducktraps in place
<solnic>
snusnu: something that didn't work at all back in DM1 days was coercion / transformation
<snusnu>
solnic: and that made me think ...
<solnic>
property stuff was making assumptions about types and it worked great for DO but it was not easy to get to work correctly with non-SQL stuff
<snusnu>
solnic: so my plan for experimenting with nest/unnest, will definitely involve ducktraps .. as ducktrap is working code that allows me to map deeply nested object graphs (that i receive from #nest)
<solnic>
snusnu: if you can do that then we've succeeded with the interface
<snusnu>
right
<solnic>
there's one thing though - session is using mapper right now to get certain info
<solnic>
like "give me key value from this object"
<solnic>
or "give me key value from this tuple"
<snusnu>
yeah, i have that in the back of my head, and it "worries" me, can't explain it, but well, we'll see
<solnic>
it might be a good idea to move that to something else
<solnic>
it also might be a good idea to just use ducktrap inside rom-mapper
<snusnu>
don't get the "worries" wrong, i'm absolutely not into session atm, so i shouldn't speak too much about it
<solnic>
as in, inherit from ROM::Mapper and use ducktrap internally in load/dump
<mbj>
I have to quit, IE8 problems in my clients stuff ;)
mbj has quit [Quit: leaving]
<snusnu>
:p
<solnic>
it's just because I started talking about session and mbj decided to leave ;)
<snusnu>
solnic: yeah, my plans are to experiment with raw ducktraps on axiom tuples .. i will have to essentially write ducktraps that "do the same" as any mapper dsl .. i hope to learn from that experience (and i'm sure that i will)
<snusnu>
solnic: mwhah
<solnic>
snusnu: we won't figure it out without experimenting
<snusnu>
right
<solnic>
I know what's needed for session, so we need to find a clean way of separating concerns so that it's easy to use non-rom mappers
<solnic>
but as I said, inheriting from rom-mapper is not a terrible thing to do for now
<solnic>
all you should care about is an object with load/dump methods after all
<solnic>
whether you must inherit from something or not shouldn't be a big concern for now
<solnic>
before all that happens we need the proxy thing
<solnic>
because once rom::relation is a proxy and then rom:session is a proxy we will be free to experiment with various approaches and when something turns out to be a good idea we could easily push it down to axiom
<skade>
snusnu: sorry, was afk for a second. thats very interesting, a writeup (even as an uncommented gist) would be very interesting
<snusnu>
solnic: +1
<snusnu>
skade: i'm using ducktrap extensively in an app that i built with https://github.com/snusnu/substation … the readme is outdated unfortunately, but it still gives a general idea of the approach i took (the code examples in the readme are mostly wrong tho :(
<snusnu>
skade: you may already see how that solves a lot of common web app problems … it protects against malformed input data, it supports mapping to nice domain objects (or rather, data capsules used by domain logic)
<snusnu>
skade: and it allows to "serialize" the same domain data capsules back to whatever the input was
<skade>
snusnu I see that, that's why this interests me :)
<snusnu>
skade: using the #inverse method .. which builds on the fact that every transformation you describe, must go both ways
<snusnu>
skade: there are quite a few, but i found that with my stuff, i typically start out with a #hash_transform
<solnic>
I'm wondering if the inverse is actually that useful in real apps?
<solnic>
when you're building output to send somewhere you're not building it from an external input, you're building it from "your own" data source
skade has quit [Ping timeout: 245 seconds]
<solnic>
and that's probably why similar libs are focused only on one direction, think about virtus and am-serializers
<snusnu>
solnic: say your app creates a new instance of something, say a person (or other deeply nested structure) .. you *might* have a ducktrap that transforms it from an external representation (say from a form) to an object .. you can then use that same ducktrap to send back any person object, you do #inverse.call and you have a hash, for easy serialization to json or whatever
<solnic>
yeahm I can see that
<snusnu>
solnic: even if you don't need to send back what you got in the first place .. since ducktrap can essentially act as a mapper, it is very useful for it to be bidirectional
skade has joined #rom-rb
<solnic>
I just never found myself doing such symmetrical transformations
<solnic>
when dumping stuff into json I always had to use custom presenters
<snusnu>
solnic: if you're doing forms "the old way" .. were you must create an html form with name/value pairs filled in (with validation errors) .. it's also very useful .. altho there is no builtin trap to do that currently .. as mbj (and i) are using angular for form stuff
<solnic>
and when building those objects from params input I had to use...custom stuff (or just AR)
<solnic>
snusnu: I want to finish this chat but I need to go now, I'll catch you later buddy
<snusnu>
solnic: hm, i guess i know what you mean .. the more you approach a design that leverages immutable instances and a real datamapper, the more useful ducktrap becomes in my (limited) experience doing so
<snusnu>
solnic: right, i was about to say the same anyway ;)
<snusnu>
and why it checks is_a?(Array) and not is_a?(Enumerable) ?
<snusnu>
this makes it impossible to render a custom enumerable using mustache sections, without calling #to_a on it …
<skade>
snusnu: i guess the idea was to cover the legacy case where Enumerator is not defined
<snusnu>
skade: yeah, pretty sure that was the case, is_a?(Array) is a rather senseless limitation tho .. really, mustache should only care wether it's an enumerable
<snusnu>
really, unintended iteration over e.g. Struct should be left to the user .. imo the right thing to do is trying to enumerate over every enumerable
cpuguy83 has joined #rom-rb
<snusnu>
namelessjon: hey, is rbnacl knowingly "broken" atm? i'm getting this after running bundle update (i use rbnacl from git for now):
<snusnu>
.gem/ruby/1.9.3/gems/ffi-1.9.0/lib/ffi/library.rb:251:in `attach_function': Function 'crypto_sign_ed25519_seedbytes' not found in [libsodium.dylib] (FFI::NotFoundError)
<dkubb>
for the record, I believe in testing public interfaces, I hate when I have to test private interfaces. I think that if you can't mutation test the whole class through the public interface, it probably means the class is doing too much
<dkubb>
I've had problems testing classes with a couple of public methods and 2-3x more private methods
<dkubb>
I also think that if you have to do lots of context blocks for a public method it means it has too many responsibilities
<dkubb>
at the same time you have to be really careful that your unit tests don't diverge into becoming integration tests, and you end up testing lots of other things besides the specific interface
<dkubb>
I think both solnic and my approach are at two ends of the spectrum, but we're both guilty of not listening to the pain in our tests.. for example, the setup in this test is much too large: https://github.com/solnic/virtus/blob/master/spec/unit/virtus/class_methods/finalize_spec.rb .. I would find it easier to follow if there were context blocks for each distinct state that is being tested
<snusnu>
dkubb: i agree with most of what you said, but i guess i'd extend it a bit .. during initial dev, it sometimes helps to have unit tests for private API in public methods, in order to keep you going .. but i'd argue that as soon as it's reasonably clear that some public methods will remain in otherwise private parts (i.e. private API), those tests can and imo should be removed, if and only if, the behavior can be tested via the public
<snusnu>
if it can't be tested that way, then the behavior itself seems dubious
<dkubb>
snusnu: when I don't know what the final interface is goingt o be, I might be more likely to write integration tests during a spike
<snusnu>
dkubb: right, i tend to do the same
<dkubb>
snusnu: much of the time integration tests can be removed later without any adverse effects
<dkubb>
or they could be slimmed down to just focus in testing the passing of message from one layer to the other; not necessarily that each layer does precisely what it should be doing, since that is now tested in the unit tests
<dkubb>
I wonder if there'd be any benefit to making a tool that tracks which tests touch which parts of the code. you could find out if there's lots of overtesting happening.. the same bits of code being touched by multiple places
skade has quit [Read error: Operation timed out]
<dkubb>
that's one of the things that makes tests brittle too
<snusnu>
dkubb: yeah, and i see another benefit from integration tests, they are the ones that actually give you a picture about how to use a system .. unit tests are often too fine grained for that
<dkubb>
oh yeah, good point
<dkubb>
you could start by writing them to support the spike, then write the unit tests, then rewrite the integration tests to be more like examples
<snusnu>
yeah
<dkubb>
I think when you start spiking you don't have a clear understanding of the usage, so if you left the integration tests as-is they couldn't be clear
<snusnu>
yup
<dkubb>
I think of coding as us presenting our mental picture of how a system should work. it's only through refactoring that we refine our understanding. tests need to be refactored too
<snusnu>
it also fits nicely with small libs that tend to expose a rather small API by definition .. a few proper integration specs might really serve as documentation, while ideally still exercising a lot of the code, giving you nice coverage
<dkubb>
a system always starts off as being a bit of a jumble of ideas because we haven't gotten a clear picture yet
<snusnu>
yeah
<mbj>
dkubb, I asked solnic and snusnu already. I'd love to present some of my ideas / spikes in a skype/hangout this weekend.
<mbj>
dkubb: And to discuss the mutant future and what to attack first in my 3weeks of pure OSS
<mbj>
dkubb: Will you have a chance to join?
skade has joined #rom-rb
<dkubb>
I might be able to. it's thanksgiving in Canada this weekend, but I may have a bit of time on Saturday
<mbj>
skade: Sorry for dropping out of the discussion. Are you interested in participating on vanguard development?
<snusnu>
dkubb: there's one thing i really want to force myself to do tho … *nuke* tests for private API … i've been bitten by having those around too often already
<mbj>
dkubb: I'll send an invitaiton email if its seems I have the time. No email and you did not missed something.
<skade>
mbj I currently dropped out of OS for similar reasons like _solnic_
<mbj>
skade: Heh, congratz.
<skade>
catch you later on that, got a meeting here
<mbj>
skade: Usually I'm 12h/day in this cannel. The following weeks are still full of clients stuff. But pls do so.
<dkubb>
snusnu: yeah, it would be easy to write a tool that scans the YARD docs and lists any tests for @api private methods. you could pipe that into rm and then run mutant to see what needs extra tests
<snusnu>
dkubb: yup exactly, that'd be neat
<dkubb>
snusnu: at the same time we need to be aware of the size of the public method specs. if they get too large I think it's a sign that the public interface has too many states to test, which roughly equates to too many responsibilities
<dkubb>
for me it's a code smell for a public method to delegate to 4-6 private methods
<dkubb>
but there are lots of cases in the ROM ecosystem where a public method is like the tip of an iceberg and delegates to a half dozen other methods
<dkubb>
and the only way to test it is with a ton of context blocks
<snusnu>
dkubb: yes i agree, large specs, lots of contexts, are a sign of too many responsibilities
<snusnu>
dkubb: btw, thx for the recent pushes towards nest/unnest! would you think that it's ready to experiment with it a bit?
<snusnu>
dkubb: i'm mainly thinking about playing around with nested relations and ducktraps (as ducktrap already can map arbitrarily nested object graphs)
<dkubb>
snusnu: I think it's probably functional enough to try out
<snusnu>
dkubb: so what i would do, is to write a few ducktraps for nested tuples returned from axiom
<snusnu>
dkubb: awesome!
<dkubb>
snusnu: if you see the PR todo list there's some extra methods I need to add, but I think those ones will go quickly
<snusnu>
dkubb: lemme have a look at that todo list ...
<dkubb>
those first 3 items are the hardest ones
* snusnu
wishes that the GH message: "SOMEONE wants to merge 20 commits into master from nested-relation" .. would expose links to those branches
<snusnu>
dkubb: are wrap/unwrap basically EV support, as opposed to nest/unnest supporting EC ?
careo has joined #rom-rb
<dkubb>
snusnu: it's hard for me to explain those because I haven't implemented them yet. I believe those ops are more like tuples inside tuples, rather than relations inside tuples
<snusnu>
dkubb: right that was my thinking, hence i made the comparison of embedded value vs. embedded collection
skade has quit [Quit: Computer has gone to sleep.]
zekefast has quit [Quit: Leaving.]
skade has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
<namelessjon>
snusnu: Not knowingly broken, but knowingly requiring the latest version for libsodium
<solnic>
dkubb: so what's your opinion on tests in descendants_tracker because these are the kind of tests we had in virtus and as you know *I deleted them*. It's really important for me to understand what's the value of writing tests so detailed that they touch internals of a library. This seems to violate one of the basic principles of not testing implementation
<solnic>
details. I felt so much pain because of such tests. Once I started focusing on the behaviour I started breathing again and I was super productive. It's pain and suffering otherwise. I don't see the value and I really tried all sorts of approaches. Current virtus test suite, although not perfect, pretty much shows what kind of tests I want to write from now
<solnic>
on. Oh and lack of mocks feels great.
<solnic>
mbj: it's gonna be hard for me to join the call during the weekend, it's the last weekend that me and my wife have some time for each other before the baby and we planned to chill out a bit; we could maybe have the call during the week instead?
<mbj>
solnic: np problem!
<mbj>
solnic: I understand.
havenwood has joined #rom-rb
<solnic>
dkubb: oh and re tests for finalize, it's the most recent addition and it hasn't gone through any kind of refactorings yet; I will probably split this spec into more granular contexts as I also don't like this particular structure; esp assertions inside the before block
cpuguy83 has quit [Remote host closed the connection]
postmodern has joined #rom-rb
cored has quit [Ping timeout: 256 seconds]
cored has joined #rom-rb
breakingthings has quit []
martxel has quit [Quit: WeeChat 0.4.1]
martxel has joined #rom-rb
martxel is now known as Guest28490
Guest28490 is now known as martxel
martxel has quit [Changing host]
martxel has joined #rom-rb
skade has joined #rom-rb
CraigBuchek has quit [Quit: CraigBuchek]
mbj has quit [Ping timeout: 252 seconds]
havenwood has quit [Remote host closed the connection]