<snusnu>
lukesutton: how's it going? you are the guy who designed the dm1 homepage, right?
<lukesutton>
snusnu: that's correct
<snusnu>
lukesutton: i still like it, even tho i tend to not use it that much anymore ;)
<lukesutton>
snusnu: It was good fun to make. I like it, even if it now looks a bit rough
<lukesutton>
snusnu: I could make something nicer now I think
<lukesutton>
snusnu: Right now, I'm investigating using ROM for a client project. But I'll admit I'm a bit lost
<snusnu>
heh, that's part of what drives us, right? once i don't think anymore that i could do something better the next time i'd do it, i guess i would quit my job :D
<snusnu>
lukesutton: well, it's early days for using it, but really, it should already work for limited scenarios
<lukesutton>
snusnu: I'm willing to be an early adopter :)
<snusnu>
awesome!
<lukesutton>
snusnu: is there anything like a 'getting started'?
<snusnu>
i'm afraid not really, at this point :/ we're planning to do a first 0.0.1 in like 2 weeks or so .. and we will definitely come up with at least preliminary docs for that
<lukesutton>
To begin with I want try it out with Postgres, but later create my own YAML adapter for Axiom
<snusnu>
postgres will be the first rdbms to be supported, all (sql) dev is done for that
<snusnu>
and it should mostly work fine for reads already
<snusnu>
it's completely missing write support tho
<snusnu>
for that, we're planning to fully incorporate the in-memory adapter for the 0.0.1 release
<snusnu>
it will be the reference adapter, just like with dm1 (only much, MUCH more powerful now ;)
<snusnu>
so the plan is to get everything working and tested against the in-memory adapter, and then tackle sql generation (again) .. adding write support
<snusnu>
also, the idea behind that is, that while you're in development, you typically wouldn't (shouldn't?) care too much wether data actually is persisted .. it's about app logic at this stage
<lukesutton>
Gotcha
<snusnu>
the way rom is designed, is that once it works against the reference adapter, it will just work (™) against any other adapter (given that is equally tested and complete)
<snusnu>
rom exposes no sql interface, it's all relational operations
<lukesutton>
It sounds close to what I'm looking for
<snusnu>
if those work against the reference implementation, and the adapter is "correct", it will just work
<lukesutton>
I'll have an app that uses different data sources depending on environment
<lukesutton>
e.g. in dev it pulls data from yaml files on disk
<lukesutton>
In production it'll use a persistent store like Postgres or Redis
<snusnu>
yeah, i'm doing the same, in development environment i just use the in-memory adapter, and i dump the in memory contents on shutdown, and load them on boot
<lukesutton>
Largely read only
<lukesutton>
ahh. Interesting.
<snusnu>
i.e., i *will* be doing that shortly
<snusnu>
;)
<lukesutton>
ha ha.
<snusnu>
it's mostly a workaround while we're missing write support, but it's totally fine for dev
<snusnu>
also, once the inmemory adapter is incorporated, it really makes no difference, from the app's pov
<snusnu>
loading/dumping like that will allow for writing seed files and persisting changes in between demo runs with customer
<lukesutton>
That's exactly where we want to be
<lukesutton>
different backends, transparent to the app
<snusnu>
that's the beauty, yeah
<lukesutton>
For example, we have one situation where we pull in a bunch of data from a REST API and cache it
<lukesutton>
We then want to be able to query it and easily map it to objects
<snusnu>
if you can fit the data into relations, i think there's nothing really stopping you from that, even in rom's current state
<snusnu>
it might be somewhat easier once we released
knowtheory has quit [Quit: Computer has gone to sleep]
<snusnu>
tbh, i'm not entirely sure about the current state wrt the in memory adapter (especially its integration into rom, i know that axiom is pretty much ready for that)
<snusnu>
but yeah, we're totally on track for the 0.0.1
<snusnu>
see the TODO files in both rom-relation and rom-mapper
<snusnu>
it's mostly about polishing yard docs and getting to full mutation coverage (which might sound harder than it actually is, we're pretty close already)
<snusnu>
lukesutton: look at that writable view and smile ;)
<lukesutton>
snusnu: it's a beautiful thing!
* lukesutton
stars it
<snusnu>
it is, right? :) and it will work with sql too eventually, or rather, with all adapters
<snusnu>
dkubb did such a great job here!
<lukesutton>
Relational algebra without the horrors of SQL
* lukesutton
weeps
<snusnu>
hah!
<lukesutton>
I love/hate SQL.
<snusnu>
heh, i can relate
<lukesutton>
I love the power of manipulating relations. But jeez, SQL hurts
<snusnu>
next up on dkubb's list is adding support for relational #group #ungroup and #wrap #unwrap
<snusnu>
the former providing support for relation valued attributes
<snusnu>
the latter for tuple valued attributes
<lukesutton>
I'm wondering if I can build on dkubb's memory adapter example to do what I need
<lukesutton>
i.e. slurp up YAML files into relations
<snusnu>
so you can write a query that gives you back: {id: 1, tasks: [{id: 1}, {id: 2}] .. that will greatly help with relationships
<snusnu>
i'm sure you could use it for that
knowtheory has joined #rom-rb
<lukesutton>
knowtheory: hi ted
<snusnu>
rom-mapper is actually just a very thin layer, that will be able to load/dump from tuples to objects and vice versa
<knowtheory>
hiya lukesutton
<snusnu>
hey knowtheory
<lukesutton>
That's what freaked me out looking at ROM. it looked so simple
<snusnu>
:)
<lukesutton>
I was expecting some crazy magic
<snusnu>
really, it's not .. it's *very* straightforward
<snusnu>
the real power comes from axiom
<lukesutton>
Are there any examples of setting up ROM? Even with just the in memory adapter?
<snusnu>
rom-relation is a very thin wrapper around axiom relations, which proxies to a relation it gets injected via #initialize, and uses the mapper (also injected in #initialize) to do the mapping
<lukesutton>
So for a query, ROM takes the restricted relation and transforms the tuples into mapped objects?
<snusnu>
hmm, just checked, the readmes got nuked because the stuff that was in dm-mapper wasn't accurate anymore
<snusnu>
yeah .. all the work is happening in the underlying axiom relation .. and the mapper works on a tuple basis
<lukesutton>
I played around with doing that myself. Enumerate over a relation, initialize a new custom object for each tuple
<snusnu>
what we'll be adding soon (it's in the todo already) .. is that the mapper will rename the axiom relation given its mapping configuration .. it will do that right when injected into a rom-relation
<lukesutton>
I was impressed with how simple it seemed
<snusnu>
this way, you will be able to use "object land" attribute names in queries, and everything just gets propagated down nicely to datastore names
<snusnu>
again, leveraging the power of axiom
<snusnu>
no crazy mapping .. it's actually just another relational rename
<knowtheory>
hey snusnu :)
<knowtheory>
how's stuff?
<snusnu>
knowtheory: doing good thx! got back to more oss after a year and a half break last autumn .. feels good .. yeah, i guess i can't really complain :)
<snusnu>
knowtheory: how's things for you?
<dkubb>
lukesutton: I'm only here for a sec, but if you want I could help you with a yaml adapter
<dkubb>
the axiom-memory-adapter is basicaly done at this point
<lukesutton>
dkubb: I would really appreciate that
<dkubb>
everything in that gist is working
<dkubb>
lukesutton: I'd like to create a few simple adapters like: csv, json, yaml
<dkubb>
lukesutton: they'll be pretty simple, one base relation per file. axiom should work with a streaming parser, so we should theoretically be able to process largist files
<dkubb>
axiom can wrap any enumerable that yields hash-like objects and it'll them into Axiom::Tuple objects. from there you can do stuff like join, restrict, limit, etc
<snusnu>
we will definitely add a readme covering the main things to know, like setting it up
<snusnu>
before 0.0.1
<lukesutton>
dkubb: that's good stuff. thank you
<lukesutton>
snusnu: I'd be happy to help. I can bring a noob's perspective :)
<snusnu>
that's cool!
<snusnu>
we're also glad to help :)
<lukesutton>
Btw, I like the new logo. it's fancy
<snusnu>
really, we need feedback asap, that's why we're pushing a release that early
<dkubb>
so in the case of, say, csv parsing you'd parse each line, and then you'd yield the data as an array where the elements in the array line up with the header of the relation
<snusnu>
yeah, kapowaz did a great job!
<dkubb>
axiom is pull based, so it will "pull" each value from the enumerable as it needs it, rather than buffering .. well most ops anyway, to join you kind of have to buffer and build and index
<dkubb>
but things like restriction should just work
<dkubb>
I guess another way to say it is that it's a streaming interface
<lukesutton>
I might have a go at adapting the example in the spec to pull from YAML rather than an infinite list
<lukesutton>
dkubb: would you mind looking at a Gist at some point in the future?
<lukesutton>
I'll hack away at something; try to get a feel for how it all hooks together
<snusnu>
dkubb: heh, that commit i pushed, drops flay from 204 to 187, and bumps flog from 13.3 to 19.4 (because of #define_dsl_method … which didn't change at all, only it got nested inside class << self)
<dkubb>
even though I don't give a ton of weight to them, I still think they are signs of quality
<dkubb>
it lets someone know the project is alive and well maintained
<dkubb>
if I see a bunch of badges with red or low coverage it makes me question the project
<dkubb>
solnic: tomorrow I can make a markdown template for the README for everyone to look at
<dkubb>
once we get on the same page we can update the gems to match
<solnic>
dkubb: it's funny you talked about this yesterday and I raised this subject too today
<solnic>
looks like we're DRIFT COMPATIBLE
<solnic>
let's kill some monsters together
<dkubb>
another thing I think we should do is put a gem "skeleton" in devtools under the "default" directory. it could include LICENSE, Guardfile, the existing default config files, .travis.yml, .rspec and other things we use in all our projects
<dkubb>
haha
<solnic>
yeah man I so want to have that too
<solnic>
however I didn't proritize that since I don't expect to create a new project anytime soon
<solnic>
when I need to create a new project I will definitely want to add "project generator" feature to devtools
<dkubb>
yeah, although I find myself using devtools init on existing projects alot. I look at the diff to see if anything is out of date. I use git add --patch to add the new stuff, and then do "git checkout ." to get rid of the changes I don't want to apply
<solnic>
btw for now I think something handy would be to add guardfile/travis.yml "providers" to devtools so we can easily sync up stuff between projects
<solnic>
yes that's what I meant too actually
<solnic>
init is not for syncing though, it overwrites stuff
<dkubb>
yeah, I wonder if something could work for both cases
<solnic>
and add missing stuff too
<dkubb>
I suppose you could have it like the rails generators, have it prompt you to overwrite
<solnic>
adds even
<dkubb>
and if the file doesn't exist, then it just adds it
<dkubb>
haha
<solnic>
yes
<dkubb>
if the file is the same, then it should just skip
<solnic>
yeah that's my idea for now actually
<solnic>
just skip it
<solnic>
do nothing
<dkubb>
that would be a safe default until we get prompting working
<solnic>
shit, I've no idea which position of badges I prefer
<dkubb>
heh
<solnic>
I'm looking at both
<dkubb>
I'd say above
<solnic>
can't decide
<solnic>
yeah above is a bit less cluttered
<dkubb>
that gap is annoying
<solnic>
did you put the bigger gap on purpose?
<solnic>
lol rite
<solnic>
I guess that answers my question
<dkubb>
actually, I'm going to try something to remove that, one sec
<solnic>
you know, I think I prefer them on top after all
<solnic>
it's just cleaner
<solnic>
dkubb: re contributing, I agree, I want to move stuff to CONTRIBUTING.md
<solnic>
oh and what about authors/credits?
<solnic>
I think I want to only have authors listed
<solnic>
since you can see all contributors using github
<dkubb>
yeah
<dkubb>
I would say primary authors
<dkubb>
it gets stupid when you list every single contributor
<solnic>
and it's not like I want to credit some people more than the others
<solnic>
and since keeping a list of ALL contributors in readme would be silly
<dkubb>
I think the gap between casual contributor and someone who contributes a ton to a gem is usually really clear
<solnic>
I'd vote for not doing that at all
<dkubb>
it's usually one or the other side of the spectrum
<solnic>
yeah cool full ack
<dkubb>
I don't think I've ever had a case where I wasn't sure whether someone deserved to be on the README or not
<solnic>
and Copyright? could just link to LICENSE file?
<dkubb>
I'd probably link to the license file
<dkubb>
since i think it applies to the whole project
<dkubb>
although ianal
<solnic>
yup
<dkubb>
markdown for the README? which style the ===== and ----- underlines for headers, or the ##, ###, etc before the header?
<dkubb>
I like md, but I don't know which header format I prefer
<dkubb>
I'd always used the === and --- version because it looks a bit better in email format, but it doesn't give you as much control over the headers
<solnic>
I prefer #
<solnic>
because it's less typing :P
<dkubb>
it's like having h1 and h2, but nothing else. with #, ## and ### you at least get h1, h2, h3 ..and so on
<dkubb>
haha
<dkubb>
one other advantage is that if the line length changes you don't have to change the underlines
<dkubb>
ok, I can get on board that
<solnic>
col
<solnic>
cool even
<dkubb>
you know, I think devtools init should just write when the file doesn't exist, and not bother with prompting
<solnic>
right
<dkubb>
if I *really* want to update the .travis.yml to the latest in the template folder, I can just rm it and do devtools init
<dkubb>
I don't mind that tiny barrier, and it means less coding
<solnic>
yes
<dkubb>
it's not like something I do very often. usually only when I come back to a project after a few months
<solnic>
exactly
<solnic>
dkubb: wdyt about having axiom org or even moving axiom projects to rom-rb org?
<dkubb>
I thought about that
<solnic>
I find myself clicking through github like stupid and having it under one org or at least two would make things easier
<dkubb>
we could move all the rom related stuff over
<solnic>
it's esp useful for issues
<solnic>
since you see all-the-things in one place
<solnic>
can you move issues between projects within an org?
<dkubb>
I don't think you can
<solnic>
that would be awesome
<solnic>
too bad
<dkubb>
but if you reference an issue it'll add that to the other issue
<dkubb>
and you can see it's state
<solnic>
right
<dkubb>
I wonder how much we should move over. would all the supporting gems be moved?
<solnic>
not sure
<solnic>
I think it would be nice to have all the related things in one place
<solnic>
support gems are kinda special though
<solnic>
they are not strictly related, it just happens we use them in axiom/rom
<solnic>
so maybe we should keep them where they are now
<solnic>
dkubb: ^^
<dkubb>
yeah I agree
<dkubb>
things like ice_nine are not core to ROM
<dkubb>
we may swap them out or change to other gems at any time
<solnic>
yes
<dkubb>
but it is unlikely we'll swap out axiom, or rom-session or something
<solnic>
very unlikely :)
<dkubb>
with those chances are we'll refactor/rewrite or otherwise update the existing gems
<dkubb>
I fully expect once we do a v1 we'll see lots of things that need tweakink
<dkubb>
*tweaking
<solnic>
for sure
<dkubb>
ok, I'm off to bed now. good night will tal to you tomorrow
<solnic>
dkubb: night!
<mbj>
dkubb: night!
mbj has quit [Ping timeout: 245 seconds]
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
mbj has joined #rom-rb
solnic has quit [Quit: Leaving...]
<snusnu>
yo mbj
theCrab has joined #rom-rb
solnic has joined #rom-rb
<mbj>
solnic: busy, sorry
<solnic>
mbj: O_o
knowtheory has quit [Quit: Computer has gone to sleep]
mbj has quit [Ping timeout: 240 seconds]
cored has joined #rom-rb
cored has joined #rom-rb
solnic has quit [Quit: Leaving...]
solnic has joined #rom-rb
mbj has joined #rom-rb
solnic has quit [Quit: Leaving...]
solnic has joined #rom-rb
solnic has quit [Remote host closed the connection]
solnic has joined #rom-rb
solnic_ has joined #rom-rb
solnic has quit [Ping timeout: 245 seconds]
solnic_ has quit [Remote host closed the connection]
solnic has joined #rom-rb
mbj has quit [Ping timeout: 248 seconds]
solnic has quit [Quit: Leaving...]
solnic has joined #rom-rb
machuga is now known as machuga|away
<dkubb>
good morning
<solnic>
dkubb: morning
<dkubb>
solnic: I saw you cleaning up some branches this morning, fwiw I use something like this to clean up merged branches: https://gist.github.com/dkubb/3218612
<solnic>
dkubb: I stole that from you YEARS AGO man ;)
<dkubb>
hehe
<snusnu>
hey guys, this just popped up in my GH feed, i wanted to bring it to your attention in case you're not watching reek
<snusnu>
the actual implementation seems like it's not tied to attr_reader's but to parameterless methods "only" (there's probably not even a way to distinguish the 2)
<solnic>
hah! they also fixed a bug in rubocop that I reported YESTERDAY
<solnic>
dkubb: ^^
<snusnu>
so there might be cases, where for performance reasons one might still want to have an lvar .. but yeah, i guess i like the change nevertheless
<solnic>
snusnu: wellllll if a method is too slow you will find that out sooner or later and fix accordingly
<snusnu>
right
<solnic>
cluttering code "just in case" is stupid
<snusnu>
agreed
<solnic>
for perf reasons that is
<dkubb>
that's a nice change
<dkubb>
I'm glad that it treats all parameter-less methods the same, whether they are attributes or computed based on object state
<snusnu>
fwiw, iirc there's no way to distinguish those anyway
<snusnu>
i'm sure dkubb has an elaborate answer, i'd just say autoload, no way (which even rhymes)
<snusnu>
dkubb: right :)
<solnic>
autoload? why?
<dkubb>
most people probably never hit the problem in thier own code
<dkubb>
there's a big difference between app and lib development
<dkubb>
you have to consider many more kinds of environments
<dkubb>
you all know this, I know ;)
<dkubb>
if autoload was thread safe I would probably use it more
<dkubb>
but it does introduce some magic into constant loading which can be problematic
<snusnu>
i never got the point of it tbh
<snusnu>
i mean, of doing autoload in the first place
<dkubb>
I experimented with it
<snusnu>
it's like having a mutable codebase (on an abstract level)
<dkubb>
it only makes a difference if you're working in an environment where you can't load stuff in a persistent manner
<dkubb>
now that I do a ton of work within guard I don't find a need
<dkubb>
and you certainly don't need it in web servers
<dkubb>
I mean web apps
<snusnu>
it always seemed to me like a trick to boot rails faster :p
<snusnu>
i realize that's not doing it justice ...
mbj has joined #rom-rb
<solnic>
hmm why we don't have Gemfile.lock checked in?
<snusnu>
because it makes no sense?
<solnic>
why?
<snusnu>
i don't see the gain, but shitloads of Gemfile.lock updates
<snusnu>
also, installing of old deps without doing bundle update
<solnic>
well, we depend on gems from git and don't pin version numbers
<solnic>
so, it might happen that somebody is cloning a repo, running bundle install and get newer versions of what we have installed
<solnic>
and stuff may fail
<snusnu>
and we should know
<snusnu>
also, our only git deps are from devtools, which is used for dev, i *want* travis to inform me when the build breaks because of new upstream deps
<solnic>
hmm ok
<solnic>
fair enough
<dkubb>
it's generally expected that gems don't check in the lock files
<solnic>
dkubb: yeah I write 4.0 code by default too
theCrab has quit [Quit: Sleeping -_-]
<dkubb>
I could care less about absolute values. what I care about is the value of something changing over time, or the value of something in relation to something I choose, like a handicap or multiplier
<solnic>
I complained to Bryan long time ago that configurable threshold would be fantastic
<dkubb>
right now stuff is based on some unknown multipler that is probably based on some kind of average for projects in CC
<solnic>
hmm I think it's based on some pre-defined fixed values that they decided make sense and are reasonable
<dkubb>
I'd guess that they chose some stats that would be hard for the average project to reach, but also not so low that it would discourage people from using the system
<solnic>
but I see totally hairy code that still gets 4.0
<solnic>
so there's that :)
<dkubb>
yeah
<dkubb>
yeah, complex metaprogramming can get a 4.0
<dkubb>
the thing is, what is it good for if I can't configure it? when every class is an "A" and I has a GPA of 4.0 with almost no effort it's harder to understand the benefits
<dkubb>
the people who *care* about code quality are his primary market, and they need a way to increase the threshold on their own
<solnic>
dkubb: chat with Bryan one day maybe
<dkubb>
yeah, if I see him at a conference I will
postmodern has joined #rom-rb
<solnic>
mbj: is possible to call super in initialize using concord already?
<mbj>
solnic: no
<mbj>
solnic: Can you ad an issue, so I dont forget this once I touch concord the next time?
<solnic>
mbj: already did a month ago :)
<mbj>
solnic: oha
<mbj>
solnic: Sorry, I totally lost track of your request.
<mbj>
solnic: I think including a module providing an initialize would work.
<solnic>
mbj: sure, that's no biggy, I was just wondering if it's done already
<dkubb>
would anyone think it was weird if we tracked code coverage separately for unit tests and integration tests, and had different coverage thresholds for each?
<dkubb>
I'm kind of always curious to know how much of a library my integration tests cover
<dkubb>
ideally I would want to cover each integration point in each lib
<mbj>
dkubb: I'd like this idea
<mbj>
dkubb: Good to experiment
<snusnu>
dkubb: i like that too … if it weren't for my integration specs (with ~93% mutcov (!)), rspec-dm2 would make refactoring a PITA (to say the least)
<snusnu>
dkubb: what i also found, is that with my integration specs in place, i typically develop a feature until it passes integration specs in ~30min, while fixing unit specs takes 2h+
<snusnu>
now that it might be only me, but yeah ...
<dkubb>
snusnu: do you ever use the unit tests to help drive your design?
<snusnu>
dkubb: i usually do, but it feels like substation is at a point already, where i can anticipate the impact of code changes i make, quality wise .. does that make sense?
solnic has quit [Quit: Leaving...]
<snusnu>
dkubb: that said, if i notice that unit specs are a pain to setup, i do get back at the code and see what's wroing
<snusnu>
dkubb: it's just that this didn't happen to me very often recently (at least, i haven't noticed it ;)
<snusnu>
dkubb: it might be a bit special in this case, because the integration specs cover so much mutations already, so really, it's easiest for me to play around with the code, while checking back with integration specs if i'm too far off
<snusnu>
dkubb: also, my brain somehow needs the new feature, in order to be motivated to change the specs .. i'm usually not a test first guy .. i play around, maybe add a few little tests here and there to strenghten my assumptions, but only after i'm happy with the code i have, i go for full unit spec coverage
<snusnu>
dkubb: it's a matter of fact, that with the amount of tests i have, it will definitely take me longer to write tests first for a larger refactoring .. also, i can't properly envision a system just from seeing tests .. seeing/writing the code, is what i need for that
<dkubb>
snusnu: do you ever just do a code spike first, then throw it away and tdd it?
<snusnu>
dkubb: tbh, very rarely .. altho one could probably say that i do it always ;) .. given that my code eventually *never* looks like what i had initially ;)
<snusnu>
dkubb: srsly tho, i rarely deliberately throw away code .. i refactor it
<snusnu>
dkubb: that's part of the fun for me
<snusnu>
dkubb: there might've been times, for smaller stuff, where i was like, ok, let's nuke it and start over properly .. but yeah, even then, i'm no TDD guy in the purest sense
<dkubb>
I was just curious
<dkubb>
I use a combination of all those approaches
<dkubb>
sometimes I spike and throw away then tdd it, sometimes I spike then refactor with or without integration tests, sometimes I backfill tests
<dkubb>
the thing is I can always look at my code later and tell what approach I used
<dkubb>
not that one is better or worse than the other, I just get different results
<snusnu>
yeah that doesn't surprise me, i suspect that if you follow TDD really rigorously and deeply examine *every* unit test (setup) that might lead to different results .. then again, and that's just my personal thing, i do enjoy *programming*, playing with the puzzle *itself*, moving things around, till it looks good … and i realize the importance, so once i'm happy with the puzzle, i make sure nobody can break it, i.e. i write tests ;
<snusnu>
dkubb: i notice that i can spend hours on solving actual code problems, but i tend to get bumpy once i only write tests for too long .. for some reason, that's no activity my brain likes to do for too long in a row
<snusnu>
dkubb: the nice thing is that 100% mutcov feels like a reward, and i like getting those ;)
<snusnu>
dkubb: that's what helps me get over the pain, heh
<xybre>
Carrot and stick approach?
mbj_ has joined #rom-rb
mbj has quit [Ping timeout: 256 seconds]
solnic has joined #rom-rb
solnic_ has joined #rom-rb
solnic has quit [Read error: Connection reset by peer]
<solnic_>
dkubb: we already track coverage only for unit tests
solnic_ has quit [Client Quit]
solnic has joined #rom-rb
solnic has quit [Read error: Connection reset by peer]
solnic has joined #rom-rb
solnic has quit [Remote host closed the connection]
solnic has joined #rom-rb
<solnic>
dkubb: are you saying that integration tests should cover a lib in some specific %?
<solnic>
cause personally, I don't care how much they cover, if I have full mut-cov in unit specs that's all I need
<dkubb>
solnic: I was thinking about tracking unit and integration coverge separately
<solnic>
as I said, we track coverage of unit tests separately already
<solnic>
it's just that we don't track coverage of integration specs
<solnic>
i'm not sure why would we want to do that
<dkubb>
I was mostly curious about integration points between methods
<dkubb>
if we're testing things in isolation that's fine. we know that the internals of the methods are behaviour exactly as expected, but we don't always know if the messages being sent by other objects are valid, except in cases where we actually use those objects
<dkubb>
which I try to do whenever they are value objects or immutable, but it's not always possible
<solnic>
well, since I started using bogus I feel way more confident about my tests
<snusnu>
solnic: you weren't logged in at the time, but i previously said that i like having reasonably strong integration specs (it always depends on the domain of course) .. it helps me with getting a feel for the progress of a refactoring, when changing unit specs right away feels like overkill
<solnic>
I know shit can break nevertheless of course, I try to write integration tests that basically check integration using some basic scenarios, nothing too crazy, I believe that should be enough
<snusnu>
solnic: i'd probably never target some crazy high (mut)cov number, but yeah ..
<solnic>
snusnu: yeah I read the logs actually
<snusnu>
solnic: ah ok
<solnic>
integration specs are great for higher-level stuff, so when I'm spiking things out I write an integration spec to get a feeling of how I wish the API would look like
<solnic>
then I make it pass
<solnic>
as in, make it pass writing whatever code that's needed
<snusnu>
solnic: tbh, i'm probably also influenced by substation atm, because the toplevel public api is so tight, that two tiny spec integration spec files get it to 93% mutcov last time i checked
<solnic>
during that process I learn what's needed
<solnic>
which gets me off of the spike phase
<snusnu>
yeah, i do that too, much more than with unit specs
<solnic>
so I usually end up with massive refactors or even re-writes
<solnic>
during which I do TDD
<solnic>
because that's the only way I can design the guts in a good way
<snusnu>
i can never resist the temptation to just write the code, if i already have an idea how it should work (which i must have, when i write a spec for it)
<snusnu>
on that unit level
<solnic>
that's super-spiking for me :)
<solnic>
I do that too, some times
<solnic>
less often these days
<snusnu>
fwiw, when i'm reasonably sure, i do both side by side, write a method + the spec .. i almost never write the spec before the implementation tho .. well, only for integration specs mostly
<snusnu>
almost always, the implementation will be fewer loc than the spec, i hate typing ...
<snusnu>
:p
<solnic>
dkubb, snusnu: I'm wondering if the schema/mapping building part should be implemented inside rom gem itself, otherwise I'd need to make relation and mapper depend on one another
<mbj_>
dkubb: okay, feel free to merge
mbj_ is now known as mbj
<mbj>
solnic: You know how to make someone permanent op? #mutant
<solnic>
geeez I knew I should've written down how to do it...
<solnic>
no, I forgot :(
<mbj>
solnic: np
snusnu has quit [Ping timeout: 256 seconds]
snusnu has joined #rom-rb
<solnic>
snusnu: ping
<snusnu>
solnic: pongh
<snusnu>
oh right .. hmm
<snusnu>
solnic: i think i don't really get the question
<Gibheer>
mbj: tell chanserv to do +O
<mbj>
Gibheer: like /msg ChanServ +0 ?
<mbj>
Gibheer: I think I must specifc channel somehow
<Gibheer>
not 0, but O (large o) and the nick name
<solnic>
mbj: O not zero
<mbj>
heh
<Gibheer>
and yes
<Gibheer>
/msg chanserv help might also help
<snusnu>
solnic: i.e. i dunno what you are suggesting? are you suggesting to not provide it with rom, or to provide it with rom?
<Gibheer>
/msg chanserv help flags is very helpful
<solnic>
snusnu: just thinking about adding user-friendly DSL to *rom* gem
<snusnu>
solnic: ah, as in, the metagem
<solnic>
and leave rom-relation and rom-mapper "bare bone"
<snusnu>
solnic: or not o meta maybe
<solnic>
I mean we need an integration point
<snusnu>
solnic: sounds feasible, yes
<solnic>
if I put it into relation/mapper then...
<solnic>
they'd have to depend on each other
<snusnu>
solnic: it's the place that pulls the others together
<solnic>
yes exactly
<solnic>
also, 99% people will be installing rom gem
<snusnu>
yeah
<solnic>
I can guarantee that
<mbj>
good idea
<solnic>
dkubb: ^^?
machuga is now known as machuga|away
<snusnu>
hm, it surely makes no sense to use rom-relation without mappers and a schema tho .. which would make it fine for rom-relation to depend on rom-mapper and provide the schema? but actually, i think i lean towards a rom-schema project
<snusnu>
because, a schema should be usable with raw axiom relations too?
<solnic>
yes it would but it would be a dsl to build axiom relations
<solnic>
I don't think it makes any sense to have it as a separate project
<snusnu>
those are just quick thoughts btw .. but yeah, a schema spanning multiple adapters should be usable with raw axiom i guess
<solnic>
its value would be so little
<snusnu>
fair enough, all we need is a place to start, we'll see where it goes from there .. so, inside rom is cool with me
<solnic>
yeah totall
<solnic>
totally even
<snusnu>
don't say
<snusnu>
:p
<solnic>
no, really man
<solnic>
I'm serious
<snusnu>
heh
<solnic>
totall was a typo ;)
<snusnu>
!
<solnic>
:)
<snusnu>
hehe .. so yeah, stuff stuff inside rom, it'd be almost empty otherwise anyway
<solnic>
well, it'll all get tricky with dsl for relationships
<snusnu>
of course, but why care now
<solnic>
I don't
<solnic>
just mentioning
<snusnu>
me neither
<snusnu>
i know
<snusnu>
heh
<solnic>
right
<snusnu>
damnit i need to get back into rom dev .. that substation sucker is so interesting tho, and also, very valuable for as atm
<snusnu>
s/us/as
<solnic>
snusnu: I'm trying to keep my mouth shut but I will yell at you in Berlin if you don't come back to rom ;)
<solnic>
choose your destiny ;)
<snusnu>
solnic: dude, i *will* come back, that's absolutely, withoutadoubt, completely, sure
<solnic>
I know I know, I'm mostly kidding ;)
<snusnu>
;)
<solnic>
just remember, if you come back and nuke everything I wrote I will KEEEEL YOUUUU
<solnic>
I'm mostly kidding once again ;)
<snusnu>
don't say
<snusnu>
:p
<solnic>
no, really
<solnic>
I don't want to go to jail
<snusnu>
but yeah, just make sure you code stuff we can use
<snusnu>
mbj: would you support a concord change that allows: include Concord.new(:foo, :bar, equalize: [:foo]) and would use all attributes as a default for equalize: [...]
<snusnu>
mbj: i found myself not being able to use concord in a class because of different equalizer behavior, when in fact, #initialize still is a simple composition
travis-ci has joined #rom-rb
travis-ci has left #rom-rb [#rom-rb]
<travis-ci>
[travis-ci] rom-rb/rom-relation#80 (relation-mapping-support - 51f1e3e : Piotr Solnica): The build was broken.
<snusnu>
mbj: and not in *one* class, but quite a few ones already, i explicitly waited to ask you that question until i had that usecase a few times
<snusnu>
mbj: "dropping back" to include Equalizer necessitates quite some boilerplate code, concord could take care of, if it were to support what i suggested
<solnic>
gotta run, good night
<mbj>
snusnu: What about to merge concord and anima in a "dto" class ?
<snusnu>
solnic: have a good night
<mbj>
solnic: have fun!
<mbj>
solnic: class => lib
<snusnu>
mbj: off the top of my head, no, and not only because dto would be a terrible name
<mbj>
hehe
<snusnu>
mbj: i surely want no attributes hash constructor interface for all my nice and tidy concord classes
<snusnu>
mbj: also, i haven't yet found a usecase (in a library) where i had to use both concord and anima
<mbj>
snusnu: TBH, I like concord and animas very very *sharp* interface
<snusnu>
mbj: that's different for apps, but yeah
<snusnu>
mbj: yeah, me too
<snusnu>
mbj: they do what they're supposed to, very little, very straightforward, very easy to remember, very bugfree
<snusnu>
mbj: only concord could use a little more power :p
<snusnu>
mbj: i'd vote for supporting #super inside #initialize of a concord infected class, plus some api to the effect of what i suggested above .. the simple hash idea seems feasible as api to me
<mbj>
snusnu: Isnt it a misdesign when you havet to equalize on other proparties than the passed in state?
<snusnu>
mbj: i thought about that too, but there are cases where one object is "dependent" on another one
<snusnu>
mbj: i.e. equalizing one is enough, because the other can be inferred from the first one
<snusnu>
mbj: fwiw, i'm not saying i *must* have this in concord, i mainly wanted to run the idea by you
<snusnu>
mbj: i will admit that probably most of the cases i had a need for it, could probably still use refactoring .. maybe it's still too early to add a feature like that to concord
<snusnu>
mbj: i should feel more pain maybe, before i start begging
<snusnu>
:p
<snusnu>
mbj: altho i have to say that i wouldn't actually subscribe to the argument that equalizing on something else than the inject state is a misdesign per se
<mbj>
snusnu: sorry, busy mom
solnic has quit [Quit: Leaving...]
<snusnu>
mbj: just think about injecting some object that doesn't need an equalizer, plus one that does
<snusnu>
mbj: no worries
<mbj>
snusnu: I need to squeeze out my small clients
<mbj>
Also if I have god relationships to them I dont make any money
<mbj>
that are the ones I started with years ago
<mbj>
But they still take some time, (each a littlebit, but this sums up)
<mbj>
s/god/good/
<mbj>
snusnu: Lets thay it this way, I'd accept such a feature in concord. But the pain must be big enough :D
<mbj>
snusnu: BTW a coworker had an interesting observation when I showed him our facades (substation), "Const heavy" :D
<mbj>
snusnu: These consts in our facade should IMHO be replaced with something in a builder object
<mbj>
So I dont have "unused" consts
<snusnu>
mbj: once the decentralized_dispatch_table branch is ready and merged, you will be able to just do that
<mbj>
snusnu: nice!
<mbj>
I'm busy
<snusnu>
mbj: it'll be up to you if you define a const or not, altho tbh, i don't yet see the real argument against them
<mbj>
totally lost track of rom*
<mbj>
and now about to loose track of substation and axiom
<snusnu>
heh
<mbj>
beginning to loose track of dkubb improving mutant :D
<snusnu>
mbj: once that's done, i guess you longer need to assign to consts
<snusnu>
mbj: the api is still open for debate of course, initially i thought about: ENV.chain(:create_person, then_comes_the_big_block)
<snusnu>
mbj: although i'd be interested in concrete arguments why const heavy is a bad thing .. the only thing i don't necessarily like, it that *not all* of them are needed … i do like to have those i build on top of, as consts tho
<snusnu>
mbj: i dunno if i can/want to come up with anything else that makes it equally succinct to build on top of an already defined chain
<snusnu>
mbj: i guess we could always use Environment#[] to get at an already defined chain, but i wonder if that'd read better
<snusnu>
mbj: one nice benefit of the consts, is a really nice yardoc for the facade
<snusnu>
mbj: and really, those *are* consts .. once constructed, they can't be changed
<snusnu>
mbj: it can be argued if they need to be named consts yeah, hm, undecided ...
<snusnu>
mbj: btw, i'd be *really* interested how you guys call the substation environment (const) in your app
<snusnu>
mbj: i hate ENV
<snusnu>
for obvious reasons ...
<snusnu>
mbj: also, i'd love to hear how/if you test your ducktraps
<snusnu>
dkubb, mbj: what would you guys think of a devtools command, something like "devtools jc", which would feed configs to flay/flog that "raise the bar" (say by lowering flay threshold/core and flog threshold) .. which would have the effect of those tools printing out references to the code that currently is the most offensive
<snusnu>
now you go figure out what "jc" stands for … :p
<snusnu>
it would kinda show the hotspots, the code that is right at the thresholds, best candidates for trying to raise the bar
<snusnu>
i realize how easy that is to achieve manually, but it sounds fun
<snusnu>
i guess reek would be a bit more involved, it'd probably have to accept switches for the smells you want to tackle
<snusnu>
every now and then, we could run devtools jc and let us be reminded of the "worst" places in the codebase
_whitelogger has joined #rom-rb
dkubb|away has joined #rom-rb
dkubb has quit [Read error: Connection reset by peer]