<NemesisD>
been closely following the rom-rb developments lately and I'm really excited for the possibilities. where is a good place for mere mortals to help out?
NemesisD has quit [Quit: WeeChat 0.4.1]
NemesisD has joined #rom-rb
cored has joined #rom-rb
cored has joined #rom-rb
snusnu has quit [Quit: Leaving.]
skade has quit [Quit: Computer has gone to sleep.]
<postmodern>
NemesisD, good question, there's the obligatory roadmap
<postmodern>
NemesisD, i believe the outstanding things are SQL write support
<postmodern>
NemesisD, and rom-session / unit-of-work code
jfredett has quit [Quit: Leaving.]
<postmodern>
NemesisD, also dkubb has some fancy ideas for using axiom to represent schema changes
franckverrot has joined #rom-rb
kapowaz has joined #rom-rb
franckverrot has quit [Ping timeout: 264 seconds]
kapowaz has quit [Ping timeout: 248 seconds]
cored has quit [Ping timeout: 245 seconds]
franckverrot has joined #rom-rb
kapowaz has joined #rom-rb
mbj has joined #rom-rb
skade has joined #rom-rb
mbj has quit [Ping timeout: 240 seconds]
NemesisD has quit [Ping timeout: 264 seconds]
skade has quit [Quit: Computer has gone to sleep.]
kenphused has quit [Remote host closed the connection]
kenphused has joined #rom-rb
really_kenphused has joined #rom-rb
kenphused has quit [Ping timeout: 240 seconds]
really_kenphused has quit [Quit: I'll Get Back With You on That in a Few]
skade has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #rom-rb
snusnu has joined #rom-rb
postmodern has quit [Quit: Leaving]
snusnu has quit [Quit: Leaving.]
breakingthings has joined #rom-rb
cored has joined #rom-rb
cored has joined #rom-rb
cored has quit [Changing host]
snusnu has joined #rom-rb
mbj has joined #rom-rb
<snusnu>
yo mbj
<snusnu>
mbj, solnic: something's fishy with devtools: https://travis-ci.org/snusnu/substation/jobs/11571913#L833 it exits with 0, but only because it runs specs *again* after running mutant .. if you scroll upwards on that page, you see that actually mutant failed
<snusnu>
solnic: fwiw, not for me, running rake ci locally does what i expect it to
<snusnu>
solnic: also, when looking at the task deps, i don't see how they would be run twice .. it's: unit => integration => metrics => mutant now
knowtheory has quit [Quit: Computer has gone to sleep]
<solnic>
snusnu: mutant task runs specs, no?
lgierth has joined #rom-rb
<lgierth>
ohai everybody
lgierth has quit [Client Quit]
<snusnu>
solnic: no?
lgierth has joined #rom-rb
<snusnu>
solnic: snippet from my console ...
<snusnu>
155 files inspected, 5 offences detected
<snusnu>
0 total warnings
<snusnu>
Mutant configuration:
<snusnu>
you see rubocop, then mutant immediately
<snusnu>
hey lgierth
<snusnu>
solnic: maybe you're not running the ci task but something else? (on travis)
<solnic>
snusnu: maybe I don’t have latest devtools
<lgierth>
are you wondering why the task chain isnt interrupted? (missed a few bits)
<snusnu>
lgierth: no, i noticed that prior to my commit, devtools, when running rake ci task, ran metrics first, then mutant, and then (only) spec:integration
<snusnu>
lgierth: and that made travis happy even when mutant was failing
<lgierth>
seeing that as well
<snusnu>
lgierth: so i changed it to run: spec:unit, spec:integration, all metric tasks, metrics:mutant
<lgierth>
snusnu, re happy travis, that's because `git rev-parse --abbrev-ref HEAD` evaluates to HEAD, not master, on travis
<snusnu>
lgierth: oh right! i remember now
<snusnu>
lgierth: still, the "new order" (heh) makes sense to me now
<lgierth>
i opened a ticket for that in devtools
<snusnu>
lgierth: looking at it right now … do we know a solid fix already?
<snusnu>
lgierth: there must be some git command that works consistently across osses ;)
<lgierth>
before_script: git checkout master
<lgierth>
but a solid one, no :)
<snusnu>
heh
<solnic>
we can check if it’s travis env
<solnic>
ENV[‘TRAVIS’] or something
<lgierth>
or somehow make rev-parse ignore HEAD
<snusnu>
so what's the issue here? does travis clone the repo in a way that the branch isn't really known?
<snusnu>
because if that's the case, the checkout master seems fair enough
<snusnu>
well actually, checkout master won't work .. at least when travis should run builds for other branches, heh
<lgierth>
yeah
<lgierth>
thinking it should skip HEAD when traversing the known refs
<lgierth>
oh i can reproduce it locallz
<lgierth>
git checkout $SHA_OF_CURRENT_HEAD; git rev-parse --abbrev-ref HEAD => HEAD
<lgierth>
and it kind of makes sense, it's simply not on any branch
dkubb has joined #rom-rb
<snusnu>
lgierth: what about relying on "git branch" command?
<dkubb>
good morning
<snusnu>
hey dkubb
<solnic>
snusnu: sorry man I was on a call
<solnic>
snusnu: I think I’m using some old task then
<solnic>
morning dkubb
<lgierth>
snusnu, it'll give you "(no branch)"
<lgierth>
because you checked out an individual commit
<snusnu>
lgierth: so, can our #master? method simply do `git branch` ~= /master/ ?
<lgierth>
no, travis checks out the individual commit and thus git branch results in "(no branch)"
<lgierth>
try it locally, git checkout $some_rev
<snusnu>
that's fine .. (no branch) doesn't match /master/
<snusnu>
ah ok
<snusnu>
well
<snusnu>
i see
<lgierth>
we could compare git rev-parse master with git rev-parse HEAD though
<lgierth>
without the option flags they both return the revision, and if it matches, we're on master
<lgierth>
will make a pr with that
<snusnu>
sounds good!
<snusnu>
mbj: ping
skade has quit [Quit: Computer has gone to sleep.]
cored has quit [Ping timeout: 260 seconds]
<lgierth>
mh, turns out we have a whole list of branches to "fail on"
<lgierth>
which currently only contains master
<lgierth>
so i'm thinking of getting a list of revs for these branches
<lgierth>
and see whether the current rev is in that list
<lgierth>
if shelling out that often (for cases where project.devtools.fail_on_branch has multiple items) becomes a problem, we can still start caching things
<solnic>
mbj, snusnu: I must admit when I say “develry” I hear “delivery"
<solnic>
:D
<solnic>
snusnu: LOL (re your latest reply)
<snusnu>
:p
<snusnu>
mbj: i just know one thing … i would be happy at work, if i could use ROM … my attitude would not change at all if there was a new rubygems
<solnic>
groceries, bbiab
<snusnu>
mbj: i have to keep posting to that thread if you don't show up here ……. :p
<mbj>
lulz
<mbj>
I had IRC open for hours without noticing it.
<mbj>
hey, hola!
<snusnu>
yo
<snusnu>
:)
<lgierth>
ohai
<mbj>
No time to consume backlog now, laters. Still busy.
<mbj>
lgierth: hola
<mbj>
dkubb: hola
<mbj>
solnic: hola
<solnic>
luls
<snusnu>
that's fun, srsly
<snusnu>
solnic: update GH
<snusnu>
;)
<solnic>
that’s interesting to see how that thread evolved
<snusnu>
i just had to say it solnic, i had to ...
<solnic>
yeah, I think you got a point there, our focus on tooling and practices etc was great but at the same time it was such a major distraction from what’s most important, which is finishing ROM
<solnic>
from my pov we should shift focus entirely now
<solnic>
finish rename process of devtools and just move on with ROM w/o touching metric stuff for some time
lgierth has quit [Quit: Ex-Chat]
<snusnu>
solnic: +1
<snusnu>
like, totally
<dkubb>
tbh, tooling is probably what keeps me interested much of the time
<dkubb>
when my motivation is low, it's what I focus on because I find it most interesting
jfredett has quit [Quit: Leaving.]
<dkubb>
and we've been using it as a gateway to bring more people in. most people can't contribute to ROM directly in axiom or rom-session/rom-mapper
<solnic>
so, you’re more into learning stuff and experimenting rather than finishing stuff in axiom and helping with ROM?
<dkubb>
I would say it's 50/50
<solnic>
I see
<snusnu>
dkubb: i can totally appreciate that, and that's why i mentioned it *first* (after some sarcastic comments in between friends) :)
<dkubb>
I definately don't like the idea of someone else setting my priorities. you can set your own
<solnic>
of course
<solnic>
I think that’s what snusnu wrote in the beginning
<dkubb>
you can ask for focus, but you can't tell it. irc is a poor medium of expression, but my interpretation is that it's being dictated, which isn't going to work for me
<dkubb>
mbj has always been focused on tooling
<dkubb>
I've been 50/50
<snusnu>
dkubb: just to make my point more clear, i'm absolutely NOT about setting priorities for anyone, i *really* know what it's like to work on OSS … at the same time … there seem to be different opinions, and imo those are best *discussed* ...
<dkubb>
and ROM itself is a tool
<mbj>
Ive been focused on tooling I need.
<mbj>
And why the heck you think I'm gonna start a rubygems soon ;)
<mbj>
For a rubygems I need persistance, and for persistance I need ROM ;)
<mbj>
Somehow my mustings about a new rubygems seem to be taken wrong.
<dkubb>
I like working on foundational tools like axiom and mutant
<snusnu>
mbj: no dude, i am completely honest when i say that you should work on what interests you most .. same goes for dkubb
<solnic>
+1 to what snusnu wrote
<solnic>
at the same time I just wanted to say it’s a bit sad for me that our goals seem to be…different
<solnic>
cause they are different, so it seems
<mbj>
solnic: You think I dont wanna finish ROM?
<dkubb>
I mean, I could easily work on rom-session and rom-mapper. I probably have the most experience maintaing libs that do something similar, but I burned out on some of that work with DM1
<dkubb>
solnic: you'll never get perfect overlap on goals
<solnic>
and I’m not trying to dictate anything, I mean, really, c’mon how could I dictate or even try to dictate anything
<dkubb>
solnic: it comes across that way sometimes
<mbj>
Lets summarize we share a substantial amount of goals ;)
<solnic>
mbj: I don’t know :)
<mbj>
solnic: I wanna finish rom. Before any rubygems/rspec replacement I plan.
<solnic>
dkubb: what comes across that way?
<snusnu>
imo it's just healthy to talk about it … we don't have to agree on everything, that's probably not possible .. but yeah, we should (be able to) discuss it openly … if *anyone* felt offended by what i said, i sincerely apologize .. that was *never* the intention
<dkubb>
solnic: that you want to dictate what everyone works on or how we work on things. it's probably the medium we're discussing things in, but it has made me angry more than once
<mbj>
Lulz we have a: "Non tech talk in chat causes confusion" - thing here.
<solnic>
dkubb: that’s probably due to the fact I’m not a native speaker and sometimes it’s just hard to express things so the sound good
<snusnu>
dkubb: there's another side to that equation too … and please take that with a grain of salt …. our metric tools dictate too ..
<solnic>
I also like discussing things, so whenever I say something it’s because I want to know what others think
<snusnu>
same goes for me
<solnic>
and I was also under impression that you guys want to work on ROM which now turns out it’s 50/50 for dkubb
<dkubb>
I want to work on ROM foundations, which I see as being axiom and mutant
<dkubb>
I can't recall the last time I actually committed to a rom-* gem.
<solnic>
dkubb: also, whenever I make you angry, dude, you have to tell me, really
<solnic>
it’s the only way for me to KNOW when it happens
<solnic>
and explain things in a better way so you no longer feel angry
<dkubb>
yeah, I know, I've got to speak up more
<dkubb>
see, the thing is rom-session and rom-mapper don't really interest me as much as axiom, because I've been there and done that. maybe what I did in DM1 isn't as sophisticated, but I don't think I have as much to learn on that end of things as on the foundations
<solnic>
yeah I get that
<snusnu>
i can totally understand that dkubb
<dkubb>
I also like mutant because it helps me to become better at testing and making code more bullet proof
<solnic>
btw I think mutant is the foundation for axiom
<mbj>
solnic: The non native speaker thing happens to me often ;)
<solnic>
not ROM
<dkubb>
I totally fucked up the DM1 foundations (well, ok, maybe not as bad as some ORMs, but still not as good as what I can do), I want to fix that first before moving my attention to higher layers
<solnic>
it may become foundation for ROM once it’s a stable project
<snusnu>
solnic: exactly
<dkubb>
I see mutant as foundational. it's probably shaping our practices more than anything else
<dkubb>
maybe it's not foundational as a kind of library, but along with immutable objects, SOLID, Tell, don't ask, and a bunch of other tools and practices it shapes how we do things
skade has joined #rom-rb
<dkubb>
even if I put all my attention on a rom-* gem right now, how could I do it so that it doesn't result in lots of contention? having solnic and snusnu working on the rom-* layer, me working on axiom and mbj working on mutant is better to avoid contention
<dkubb>
we communicate through interfaces fairly well right now. I'm happy with how rom is looking to be a proxy on top of axiom, that was my intention right from the beginning and I'm glad to see it happening
<solnic>
given you’re the only person who can work on axiom I don’t think it’s a good idea if you started working on, let’s say, rom-mapper :D
<dkubb>
mbj can work on axiom too if we needed it, but I think we'd probably have lots of contention, unless we were focusing on different gems and limiting our contention on the interfaces
<solnic>
that’s good to know
<mbj>
Ack with dkubs claim, I feel confindent I could work in axiom.
<dkubb>
that seems to be a pattern that works well. we generally don't modify the same gems at the same time
<mbj>
a/clame/statement/ # not a native speaker issue
<dkubb>
axiom itself is lots of files, but they're stupid simple
<dkubb>
I'm confident I could teach any developer enough to contribute to axiom within 5-10 hours
<snusnu>
hmm dkubb, you really think so? one that doesn't know RA in and out?
<mbj>
dkubb: Also with using tooling correctly?
<dkubb>
snusnu: yeah, RA isn't complex. it's basically the equivalent of addition/subtraction/multiplication/division with sets instead of numbers
<dkubb>
it's not even equivalent to more complex maths.. it's basically grade-school level math, with sets
<solnic>
also, when I wrote “we should focus on blahblah” I meant that IMHO people who are *willing* to work on ROM should be focused more on getting it to work w/o focusing too much on metric stuff because ROM is *experimental* and I’ve found the practices behind axiom to be extremely conservative turning 1 hour tasks into days (*days*) of development and
<solnic>
it’s kinda silly when you’re working on something experimental
<snusnu>
dkubb: i "know", but i also know, that there are a lot of students, who don't even get RA in a whole course at uni
<dkubb>
snusnu: yeah, I think it's partly because of how it's taught
<solnic>
yeah RA was the simplest part of math at the uni :)
<mbj>
snusnu: These guys are typically not to be labeled "developers"
<solnic>
the only one I passed with a decent grade :P
<snusnu>
dkubb: yup, i agree .. and it depends on the mindset you're in at the time of learning, of course … i was one of those that never understood it back at uni .. now that i'm a coder, it'd be far easier (heck, it is far easier)
<dkubb>
sometimes the symbols make it harder to understand until you get the concepts
<dkubb>
(mouse over the operations)
<mbj>
dkubb: +1
<mbj>
dkubb: Symbols made math crazy hard for me
<mbj>
dkubb: I expanded them into nested and paranthesed representation for some time
<solnic>
protip: U is not a letter there ;)
<mbj>
dkubb: Until my brain is able to "autocollapse" into symbols.
<dkubb>
for some reason I understand "A union B" better than "A U B"
<solnic>
damn, I’m back at studies now (when looking at it)
<dkubb>
or a.union(b) .. or even a | b
<mbj>
Heh, we all trained to parse keywords like hell.
<mbj>
keyWORDS
<snusnu>
i don't want to go on and on here .. but here's another thing, axiom is not only RA .. it is a library with a *very specific* vision of *how it should be done* … the techniques used in there, are *not* for the average ruby coder … the tools we use, are *not* for the average ruby coder … and i don't mean any negative meaning by average ruby coder, i just mean people who are not currently following all the same practices, and the
<snusnu>
so sometimes it feels like our contribution barrier is really high … and i see no reason, why it must be that high for *ROM* .. because rom is experimental currently
<snusnu>
i wholeheartedly agree with the axiom process, it's *not* experimental anymore .. it *MUST* be rocksolidstable
<solnic>
true, I agree
<dkubb>
all of the projects adopt the different metrics to a different degree
<solnic>
the thing is we tried to do things the same way as it was done in axiom
<solnic>
and after some time my conclusion is that it was not a great idea
<solnic>
I mean, I’ve learned SO MUCH while doing that
<solnic>
but for the project itself it meant months and months and months and then more months of ad-hoc OSS hacking w/o accomplishing a lot
<dkubb>
yeah, and from my pov, I don't see any other gems coming close yet (aside from some of the smaller supporting gems)
<snusnu>
dkubb: can you elaborate a bit on that? do you mean nr of LOCS in that style?
<mbj>
dkubb: hehe mutant is my ugly secret when it comes to metrics.
<solnic>
yes, I would like to know more about not coming close yet
<dkubb>
I see them more as picking and choosing which things to follow, which is totally fine. I want to see all the 1.0 gems adopting it though, but until then I'm fine with people choosing the things that make sense
<solnic>
for example?
skade has quit [Quit: Computer has gone to sleep.]
<snusnu>
we have quite a number of gems that (imo) quality wise are comparable to axiom, as they follow the same metric stack, and have reasonably low thresholds too … the "only" thing left, is size of the project .. axiom probably is the biggest to that respect
<snusnu>
dkubb: i hope you know how i mean that, in *no way* i want to dimish the value of axiom
<dkubb>
well, I think axiom itself isn't perfect either
<dkubb>
I still have a whole bunch of mutations to kill
jfredett has joined #rom-rb
<dkubb>
axiom needs to be broken down too
<snusnu>
dkubb: yeah, the fun thing with software (and what keeps me writing it) .. is that it's never ready .. you can (and will) always find ways to make it better ;)
<solnic>
yes, software will never be perfect, I’m just intrigued by the ‘other gems not coming close yet'
<solnic>
is it about overall complexity of specific objects/methods? or maybe mutation coverage? yard docs?
<dkubb>
I shouldn't have compared absolutes. that was wrong. the trend is certainly improving
<solnic>
for me the most important thing are good tests
<solnic>
I’m starting to care less and less about what reek has to say, for example
<dkubb>
although more YARD docs would be nice :P
<solnic>
because my brain is doing a better job at finding problematic parts of the code I’ve written
<solnic>
you know what I think about full doc coverage of a library that changes every single month
<dkubb>
I wonder if there's a software rule that goes something like "a metric will decline in importance as the developer begins to adjust their style to find the problems beforehand"
<dkubb>
that doesn't mean it's not important to other contributors who haven't made that transition
<dkubb>
just like someday maybe mutant won't be as important in finding missing mutations
<snusnu>
dkubb: i'd +1 that
<dkubb>
for us anyway
<dkubb>
for new people it would still be needed, because they haven't gone through that journey yet
<solnic>
I agree with this
<solnic>
I said something similar to mbj the other day
<mbj>
hehe, yeah
<dkubb>
I've even noticed myself that new code has far less mutations that mutant finds
<solnic>
that after some time you start writing tests that are just better than before
<solnic>
and you’re killing mutations by default :)
<solnic>
which is a great great thing
<mbj>
But remember, we all *will* skip over stuff metric tools will find.
<mbj>
I'll never ever archive 100% by default.
<mbj>
But see my current project, for some tech reasons we cannot use all our devtools.
<dkubb>
you always will. you have to weight the importance of the metric warning with your current priorities
<solnic>
no but over time I’m sure you started covering much more than you did in the past
<mbj>
And I still think I do better than before using that ools.
<solnic>
yup
<dkubb>
that doesn't mean the metric is meaningless, it just means that "right now I choose to ignore this because it conflicts with something more important"
<mbj>
Actually lots of better.
<mbj>
Each dev should beforeced to write a non trivial lib that is 100% metrics covered by devtools. At least *once*.
<snusnu>
mbj: i don't agree
<snusnu>
mbj: each dev shall find his way
<snusnu>
who are we to force our way on others
<dkubb>
what I think most peolpe complain about with metrics is not necessarily that it flagged something, it's that it keeps pounding into them "this code isn't good enough" and there's no good ways to temporarily ignore it
<dkubb>
forced isn't a good word
<snusnu>
mbj: that was generally speaking btw, i'm sure you've noticed ;)
<dkubb>
pursuaded
<snusnu>
yeah
<dkubb>
we can tell devs "you will be a better developer after doing this"
<mbj>
snusnu: I dont think I'll force anything our our contributors.
<dkubb>
I can pretty much gaurantee it
<dkubb>
unless you are a freaking coding god
<snusnu>
dkubb: absolutely, that's the way i see it too ..
<mbj>
English problem
<mbj>
I ment something like "Each dev should try $foo" in his livetime.
<mbj>
Doing assembly gave me lots of insight
<dkubb>
but frankly, even the "best" rubyists I see would benefit from it
<snusnu>
mbj: i know :) and i said what i said to make that obvious to everyone
<mbj>
I wasnt about to force anything.
<mbj>
snusnu: thx
<dkubb>
anyway, my hope is that as gems go closer to 1.0 we try to be as strict as possible on the things we agree on. axiom is closer to 1.0, in terms of interface, compared to other gems, so I want to continue raising the bar there
<snusnu>
dkubb: i totally agree with that
<dkubb>
axiom-types was the first extraction from axiom, and aside from the bug solnic found, it's as close to being "done" as anything in the axiom namespace
<solnic>
I’d suggest one thing there, ditch class-based approach
<dkubb>
I want to extract other things from axiom to make it simpler too. it's too large. it confuses relational algebra and simple predicate logic, the latter being the foundation for the former, but not strictly required
<mbj>
dkubb: To clarify you are talking about "public interface and invariants there".
<dkubb>
mbj: yeah, interface is almost always my #1 priority over everything else
<dkubb>
public interface
<mbj>
dkubb: check, thx.
<dkubb>
if you have a shitty interface, nothing else matters
<dkubb>
it doesn't matter how well composed, how mutation covered things are, etc
<dkubb>
everyone has different styles too. I've noticed I work faster with more constraints than without. some people can't work like that. all I care about is that we're moving towards and not away from our ideals as we approach 1.0 in each gem
<solnic>
working with constraints makes sense when a library is no longer experimental
<solnic>
when it’s approaching 1.0
<snusnu>
dkubb: i agree with that .. the trend should always evolve towards being stricter, focused on topnotch quality etc … but we have to make tradeoffs on the way there … it's easy to think of newfound practices as silver bullets .. it happens always … we must keep reminding ourselves that, if anything, we must constantly be aware of that
<solnic>
fwiw I don’t think 0.1.0 is close to 1.0
<solnic>
I just don’t see any value in putting very strict constraints when developing a new library
<solnic>
like that method should not have more than XYZ LOC
<solnic>
because that’s so irrelevant when you’re in the middle of figuring out HOW a library should work, how the interface should look like
NemesisD has joined #rom-rb
<solnic>
I also disagree that focusing on full mutation coverage early on is a good idea
<solnic>
sure, your code will be better
<solnic>
but if you decide to change it 10 times before going 1.0
<solnic>
then you’re gonna waste a lot of time
<solnic>
from what I’ve seen a nicely tested lib will have ~90% mut coverage, those missing 10% are mostly some edge cases or just “rare” cases of usage; I totally see the value of catching them early because we know how hard it is to fix them later
<solnic>
at the same time when we’re talking about an immature library then I think it’s better to push it early and see what happens
<solnic>
after receiving first feedback, after proving that it makes sense (at a higher level)
<solnic>
you can focus on refactorings, simplify stuff, maybe extract something into a separate lib, kill mutations etc
<dkubb>
yeah, I agree with all that. I don't know if I've ever disagreed with that, but if I gave you the impression then I'm sorry about that
<solnic>
you totally gave that impression :D
<solnic>
it’s everything that I’m trying to express of the last few months
<solnic>
of/for
<dkubb>
I see code quality as a spectrum. I don't like to see regressions, but I don't care if it's staying the same on the spectrum as long as the intention is to move it up
<dkubb>
regressions really is the thing I care most about
<dkubb>
if I see a 20 line method I'm going to say something about it :P
<dkubb>
k, I'm being called into to focus on something for work so I'll bbl
<NemesisD>
solnic: out of curiousity, do you do any testing with quickcheck-like tools. basically invariant testing
<solnic>
NemesisD: not yet but I wanted to experiment with this. I remember somebody mentioning it when commenting on my post about mutant
<mbj>
snusnu, NemesisD: Can you point me to the tool?
<mbj>
solnic: I ment you ;)
<solnic>
sorry but I gtg, good night everyone
<mbj>
solnic: have fun!, np and cu
<snusnu>
solnic: good night :)
<postmodern>
i finally know how to pronounce solnic's lastname
mbj has quit [Ping timeout: 260 seconds]
snusnu has quit [Quit: Leaving.]
skade has joined #rom-rb
<solnic>
postmodern: haha fwiw it’s the same with my nickanem
<solnic>
nickname even
<solnic>
but that’s ok, I’m used to being called with english accent really
<postmodern>
i've heard several interpretations of piotr
<NemesisD>
i'm not sure of the best ruby tool for invariant testing right now. in haskell we have quickcheck
<NemesisD>
most implementations i've hard of have been ports of quickcheck
<NemesisD>
i've found quickcheck pretty valuable for finding edge cases in roundtrip-able operations like serialization/deserialization
<NemesisD>
for instance in my projects with json, when I write json parse/serialize code, i always have a property that checks that any instance of the object survives around a roundtrip through json
breakingthings has quit []
snusnu has joined #rom-rb
snusnu1 has joined #rom-rb
snusnu1 has quit [Client Quit]
snusnu has quit [Ping timeout: 264 seconds]
<postmodern>
solnic, the coercible API still confuses me
snusnu has joined #rom-rb
<postmodern>
solnic, would you be open to refactoring it's public API
<postmodern>
solnic, i think something like coercer[FromClass][ToClass].coerce(data) would be more simple
<postmodern>
solnic, or even just coercer[FromClass, ToClass].coerce ...
<postmodern>
solnic, specifying the class then using a to_foo method seems asymmetrical
dbussink has quit [Ping timeout: 268 seconds]
dbussink has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #rom-rb
<postmodern>
solnic, or maybe from_foo.to_bar
skade has quit [Quit: Computer has gone to sleep.]