ptico has quit [Remote host closed the connection]
lgierth has joined #rom-rb
therabidbanana has quit [Quit: leaving]
CraigBuchek has quit [Quit: Leaving.]
lgierth has quit [Ping timeout: 252 seconds]
solnic has joined #rom-rb
solnic has quit [Ping timeout: 245 seconds]
skade has joined #rom-rb
skade has quit [Ping timeout: 258 seconds]
mbj has joined #rom-rb
skade has joined #rom-rb
lgierth has joined #rom-rb
lgierth has quit [Remote host closed the connection]
lgierth has joined #rom-rb
skade has quit [Ping timeout: 252 seconds]
mbj has quit [Ping timeout: 258 seconds]
skade has joined #rom-rb
skade has quit [Ping timeout: 258 seconds]
solnic has joined #rom-rb
skade has joined #rom-rb
solnic has quit [Ping timeout: 260 seconds]
skade has quit [Ping timeout: 240 seconds]
lgierth has quit [Quit: Ex-Chat]
solnic has joined #rom-rb
skade has joined #rom-rb
solnic has quit [Ping timeout: 250 seconds]
vsorlov has joined #rom-rb
skade has quit [Ping timeout: 252 seconds]
vsorlov has quit [Ping timeout: 240 seconds]
skade has joined #rom-rb
solnic has joined #rom-rb
solnic has quit [Ping timeout: 255 seconds]
sferik has joined #rom-rb
skade has quit [Read error: Connection reset by peer]
skade has joined #rom-rb
skade has quit [Ping timeout: 258 seconds]
kleech has joined #rom-rb
skade has joined #rom-rb
solnic has joined #rom-rb
CraigBuchek has joined #rom-rb
CraigBuchek has quit [Ping timeout: 240 seconds]
sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
snusnu has joined #rom-rb
sferik has joined #rom-rb
robmiller has joined #rom-rb
CraigBuchek has joined #rom-rb
CraigBuchek has quit [Ping timeout: 245 seconds]
robmiller has quit [Quit: Leaving.]
robmiller has joined #rom-rb
sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sferik has joined #rom-rb
mbj has joined #rom-rb
CraigBuchek has joined #rom-rb
CraigBuchek has quit [Ping timeout: 276 seconds]
<snusnu>
yo mbj
<snusnu>
mbj: do you think it's worth having include Anima::Private.new(:foo, :bar) ?
<snusnu>
i have a few instances were i manually set the visibility to private, no big deal, just wondering if you had a few such situations too?
sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kleech_ has joined #rom-rb
<snusnu>
fwiw, i do that for classes that expose a different interface (mostly #call) but need internal data to implement that
sferik has joined #rom-rb
sferik has quit [Client Quit]
kleech has quit [Ping timeout: 240 seconds]
<snusnu>
yo solnic, around?
<solnic>
snusnu: yo
postmodern has quit [Quit: Leaving]
skade has quit [Ping timeout: 245 seconds]
skade has joined #rom-rb
CraigBuchek has joined #rom-rb
skade has quit [Ping timeout: 252 seconds]
CraigBuchek has quit [Ping timeout: 245 seconds]
sferik has joined #rom-rb
skade has joined #rom-rb
<snusnu>
solnic: re your "concerns" against too much upfront setup if a mapper doesn't expose relational ops like join, group, etc … the way i see it is this: it really depends on the application architecture, at *some* point the relation has to be specified anyway, either upfront or "inline" … the way my app is architected (thus the way i prefer), i find it much easier to specify stuff upfront
<snusnu>
solnic: i guess what i'm getting at is this .. i will write/continue to write, my own little rom, all i need is plain axiom relations and my subway mappers
<snusnu>
solnic: at some point (hopefully soon?) .. i will write axiom-schema tho … currently, i have no real need, because of the fact that i still need DM1 for writes (and a few plugins) and i have some code that converts a DM1 schema into a hash of axiom relations
<solnic>
well ok
<solnic>
I'm having hard time trying to imagine working on anything where every query that involves joining requires its own relation in the schema but if it works for then sure
<solnic>
for you*
<solnic>
it does suck for me that the three of us couldn't manage to work together on ROM though
<solnic>
it seems like the needs and ideas are too different, that's fine though
<solnic>
I'm starting using ROM on production soon however only for reading (obviously)
<solnic>
I may use Sequel for writing if it's needed, not sure yet
<solnic>
snusnu: what's missing on rom mappers that you can't use them?
<solnic>
s/on/in/
<snusnu>
yeah, i've considered sequel too, but due to my familiarity with DM1 i took that route
<solnic>
too bad, sequel is awesome
<solnic>
I'm using it w/o the models
<snusnu>
it's not so much that anything is missing, it's "just" that i use my mappers/morphers for a lot of other stuff, generate my domain objects from them, and in general, out of personal preference, really don't need relational ops on them
<solnic>
feels so good
<snusnu>
nice, that's great to hear
<solnic>
relational ops on mappers are only needed to construct wrap/group
<snusnu>
you know, i have a few plugins i wrote myself that i'm using, and yeah, i guess i just use DM1 out of habit :)
<solnic>
it achieves what you need
<solnic>
so I'm not sure why you think you don't need them, you don't have to use them if you configure relations upfront you won't even know it's happening under the hood
<snusnu>
my mappers achieve that too, or rather, they don't have to, because i set up the relations upfront
<solnic>
you can do group/wrap in the schema and get what you need
<solnic>
use that relation with mappers that will load the whole nested graph
<solnic>
I'll be adding automapping tomorrow
<solnic>
and entity generator
<solnic>
so it's gonna be inline with what you need
<solnic>
it *does* sadden me that you diverged and stopped contributing, we do have the same goal
<solnic>
we keep crashing on walls full of tiny little implementation details, the same thing happens with me and mbj wrt session and related stuff
skade has quit [Ping timeout: 258 seconds]
<solnic>
anyway, I'm gonna add some really nice features tomorrow and start using it on production and see how it goes
<solnic>
maybe there's a chance you'll find it to be usable for your use cases
<solnic>
snusnu: ^^
<snusnu>
i realize that we're duplicating some work here, but really, i need to move at my own pace here, don't have a lot of time to discuss api, don't wanna spend time on supporting stuff i might not need, need to move forward in terms of validation/coercion etc .. and in general, get a feeling for it … i hope you don't see that as rude or anything .. it's just that at this point, i need stuff that works, and i need it "under my control"
<solnic>
yeah I get that really no worries man
<solnic>
but it can make me sad a little but, can't it? :D
<solnic>
s/but/bit
<snusnu>
i'm still convinced that at some point, we can extract the best out of both worlds, as we'll have a clearer picture about the various usecases (and app architectures to integrate with)
<snusnu>
it can dude! and in fact, it makes me a little sad too, trust me
<solnic>
yes that is very very true good things will come out of that
<solnic>
I'm just fairly certain rom will provide what you need...like...tomorrow well ok maybe next week ;)
<snusnu>
hehe, i don't even doubt that dude, i just can't justify switching lots of our codebase at this time
<solnic>
I know, right
<solnic>
inorite*
skade has joined #rom-rb
<snusnu>
i built what i needed in terms of mapping with morpher, and i'm really happy with it .. i use it in a few contexts completely unrelated to relations, and i wanna reuse those same things in the context of relations .. also, my take on specifying stuff upfront is heavily inspired by my application architecture (based on substation/subway)
<solnic>
that's a nice experiment
<solnic>
I like that morpher works for you
<solnic>
makes me more confident
<solnic>
well ok, I'll just keep calm and carry on
<solnic>
oh and btw I am not surprised or anything, I pretty much knew already that it's gonna be like that but thanks for talking to me, I really appreciate that
sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<snusnu>
so what i do is basically this (only steps involving a mapper, there's other stuff happening):
<snusnu>
1) deserialize rack body with MultiJson
<snusnu>
2) sanitize that using my mappers (keeping params as a *hash*)
<snusnu>
3) adapt/extend these hashes with data needed for persistence (created_at, created_by, etc), merge default values, still keeping them as a hash
<snusnu>
4) send that (nested) hash to DM1 create/update
<snusnu>
5) read axiom relations (base and "virtual")
<snusnu>
6) reuse my mappers to get at objects
<snusnu>
7) wrap them in presenters if necessary
<snusnu>
8) wrap them in mustache views or json responders
<solnic>
you don't map relation tuples to domain objects?
<snusnu>
i do that in 6)
<solnic>
ah sorry missed that point
<snusnu>
altho i'd love for axiom tuples to respond_to the respective method calls
<snusnu>
altho i realize that this would need (quite) a bit of change
<snusnu>
because axiom tuples expose relational ops too
<solnic>
yeah I thought about it the other day
<solnic>
it feels like tuples could be structs or something
<snusnu>
there'd be too many name clashes for a simple method_missing trick
<snusnu>
yeah
<solnic>
eventually tuples will feel like an unncessecery IR
<snusnu>
inside some wrapper
<snusnu>
i don't think so actually, i think that the objects wrapping them are useless
<snusnu>
if tuples were structs, i'd just display them directly
<solnic>
depends
<solnic>
(as always)
<snusnu>
of course
<solnic>
sometimes you want to map to richer objects
sferik has joined #rom-rb
<solnic>
that's where mappers kick in
<snusnu>
wdym with richer objects?
<solnic>
I think schema should coerce to primitive types and mappers should coerce to rich domain types if you want to do that
<snusnu>
i typically fetch data from the db, and then have presenters and/or view objects
<snusnu>
(i do everything with mustache)
<snusnu>
so really, i only decorate returned tuples
<solnic>
you just didn't have a use case for it yet
<snusnu>
yeah
<snusnu>
what was yours? (just curious)
<solnic>
I didn't have one yet
<solnic>
well, I did but not with rom
<snusnu>
dare i say then don't bother?
<snusnu>
ok
<solnic>
I'm talking about things like we had in DM!
<solnic>
DM1
<solnic>
UUID, IpAddress stuff like that
<snusnu>
DM1 got it so wrong
<solnic>
terribly wrong
<solnic>
I know, don't have to remind me
<snusnu>
;)
<solnic>
and I already see that in ROM it's the way it should be ;)
<solnic>
schema gives you back tuples with primitves
<solnic>
mappers can turn some primitives into richer objects
<solnic>
notice that I'm not talking about nested object graphs
<solnic>
you use those mappers for loading stuff from the db too?
<snusnu>
solnic: one thing i happened to need, is the ability to either reuse existing mappers for wrapped/grouped tuples, or specify new, anonymous ones inline .. that's very handy
<snusnu>
altho i have some local stuff that's not really solid atm, which allows to add/remove certain attributes from mappers
<solnic>
guarding is not really needed
<snusnu>
so i can reuse a parameter mapper, but add only, say, an :id
<solnic>
when loading data from the db
<snusnu>
yeah, those are when data comes in
<solnic>
unless you want to be paranoid and don't trust axiom/db driver
<solnic>
it's really only needed when you're doing some work on a legacy db and you defined validation rules in your app's domain and you want to see if data are invalid
<snusnu>
ok, so the full picture i currently do is this, i have mappers for parameters, and ones for loaded tuples .. there's still a lot of duplication in them, but that's the part i'm working on/off .. reuse/build on top of already defined mappers
<snusnu>
of course, i know that
<snusnu>
basically, at this point, i generate the mappers for database tuples automatically from DM1 models
<snusnu>
and i have others, that work on top of upfront defined virtual relations
<snusnu>
those still have what feels like a little bit of duplication with some parameter mappers
solnic_ has joined #rom-rb
<snusnu>
one imo crucial thing for rom write ops is this: allow params to be hashes
<snusnu>
there's no need to convert those into objects, they simply need to be sanitized and validated
<snusnu>
and if there's a need for objects (i had none so far) .. rom should support both
CraigBuchek has joined #rom-rb
solnic has quit [Ping timeout: 240 seconds]
<snusnu>
in all my app's usecases, so far, it *never* makes sense to turn incoming param hashes into an object, only to store it inside the db, hashes are fully sufficient
<snusnu>
btw, i know i've said that a million times already .. but i guess you'd understand my decisions a bit better once i finally got around to writing at least the core of the project i've mentioned already, with my stack
CraigBuchek has quit [Ping timeout: 252 seconds]
<solnic_>
snusnu: yeah this is a clear separation between reading and writing
<solnic_>
and tbh I think it's a good thing to do
<solnic_>
reading data is just a separate concern
<solnic_>
blah I was supposed to go ;)
<snusnu>
hehe, go now
<snusnu>
;)
<snusnu>
i do too
<snusnu>
one last thing .. that's *exactly* the point, preparing parameters for app consumption, is different from mapping back tuples .. as it happens tho, both benefit from mappers/morphers .. when data comes in, a mapper/morpher, to be precise, a hash transforming morpher, can guard against invalid params (doing coercion, validation, extension) .. and on the way out, we trust the database and simply provide mappers for turning the tuples
<snusnu>
possibly with what you called "rich" mapping, which imo basically boils down to what DM1 named custom types
<snusnu>
but only for read
<snusnu>
and there is my reason for not needing relational ops on mappers, but instead have a nice way to hook in coercion/validation/extension
<snusnu>
the way my app is architected with substation chains, not everything is done at the same time, but my mapper DSL (specifically the extensible "types") allow for centralized declaration of all the info needed to perform the task
<snusnu>
it looks like DM1's custom types on the outside, but the system is processing it in a different way
sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sferik has joined #rom-rb
kleech_ has quit []
CraigBuchek has joined #rom-rb
CraigBuchek has quit [Ping timeout: 240 seconds]
<mbj>
CraigBuchek has joined #rom-rb
sferik_ has joined #rom-rb
sferik has quit [Ping timeout: 252 seconds]
CraigBuchek is now known as CraigBuchek|922
sferik has joined #rom-rb
sferik_ has quit [Ping timeout: 252 seconds]
sferik has quit [Read error: Connection reset by peer]
sferik has joined #rom-rb
therabidbanana has joined #rom-rb
sferik has quit [Client Quit]
snusnu has quit [Quit: Leaving.]
mbj_ has joined #rom-rb
mbj has quit [Ping timeout: 245 seconds]
sferik has joined #rom-rb
vsorlov has joined #rom-rb
snusnu has joined #rom-rb
skade has quit [Ping timeout: 265 seconds]
lgierth has joined #rom-rb
vsorlov has quit [Read error: Connection reset by peer]
vsorlov has joined #rom-rb
sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sferik has joined #rom-rb
CraigBuchek|922 is now known as CraigBuchek|1194
vsorlov has quit [Ping timeout: 240 seconds]
CraigBuchek|1194 is now known as CraigBuchek|907
<xybre>
Just got caught up with the backlog after seeing the Twitter conversation. Intersting stuff.
<xybre>
I'm not sure what the discussion about multiple smaller gems is about. Most of the ROM support gems are useful on their own as evidenced by how many people are using components of ROM but not the whole thing. Morpher and Axiom are probably at the top of that heap.
<xybre>
The DM-1 extracted gems like Virtus and Coercible are basically unrelated, but also useful on their own. If/When Coercible is refactored to use Morpher then even better.
robmiller has quit [Quit: Leaving.]
<mbj_>
xybre: I see it the same way. Nothing to add.
mbj_ is now known as mbj
<xybre>
I know there's been some arguments against ecosystem development, but it really seems much more that they're just libraries written by the same group.
<xybre>
Many of the tools are related to domain modeling and persistence, but there's also testing and object safety libraries being developed which are often reused throughout this particular group as well as externally by many others.
<mbj>
xybre: As Dan (dkubb) said before: Most of the support gems will live longer than an ROM.
<mbj>
Because they are very simple with a narrow interface.
<xybre>
I would very much like ROM to mature as its own entity, I'm sick of ActiveRecord and ActiveSupport, but I can't say that it should be the sole focus here. I don't think anyone here has a single project that makes them ignore all others, and I don't tihnk ROM should be the exception to that.
snusnu has quit [Quit: Leaving.]
sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mbj>
xybre: As long we follow the rules of zero core extensions + small public interfaces I think that'll happen.
mbj has quit [Quit: leaving]
<xybre>
I also don't think that CI errors that the maintainer handles should be a huge concerns to contributors. But at the same time, we should follow the code style guidelines for projects we contribute to, if just to make things less messy for everyone. I don't like a lot of friction when I'm developing either, but I do like to have my work checked by both automated systems and other people when possible.
<xybre>
There might be some truth that putting too much trust in metrics is an anti-pattern, but I'm not curently aware of a situation where that is the case.
robmiller has joined #rom-rb
<xybre>
Well, I take that back. Metrics are a form of statistics and they are endlessly misinterpreted and abused and one should always look at them with a critical eye. But in the case of code quality metrics, there is typically more benefit than gain. I personally prefer to put them at a threshold that will notify me when something needs to have a look taken at but no more.
<xybre>
Haha "more benefit than gain". I'll let you work out what I actually meant.
<xybre>
In my more involved projects I use Travis, Coveralls, Code Climate, and Rubocop.
robmiller has quit [Quit: Leaving.]
mbj has joined #rom-rb
CraigBuchek|907 is now known as CraigBuchek|1194
robmiller has joined #rom-rb
robmiller has quit [Quit: Leaving.]
lgierth has quit [Quit: Ex-Chat]
solnic has joined #rom-rb
<solnic>
xybre: thanks for chiming in, I just read the logs
<xybre>
Yeah I saw the Twitter convo and read the backlog. Lots of good discussion going on here.
<solnic>
xybre: I don't think anybody can convince me that failing builds because of metric feedback is a good idea
<solnic>
*especially* when I'm developing an experimental library
<solnic>
it works fine for tiny libs though
<solnic>
but not for bigger experimental stuff
<solnic>
ROM is a good example
<solnic>
when I say ROM I mean rom-rb/rom
<xybre>
solnic: I think it'd be nicer for them to be separate from the main builds, like how CodeClimate works.
<solnic>
yep
<solnic>
I also really like the idea of using metric feedback and do refactorings on a regular basis but not *on a daily* basis
<solnic>
for instance before a major release
<xybre>
If you're working on an experimental library then its less useful, but as we all know, prototypes are shippped as production to users every day.
<solnic>
or maybe even before *any* release
<solnic>
xybre: yeah man, I'm against releasing prototypes and saying "HERE IT WORKS GO USE IT" ;)
<xybre>
I had this process idea that following Semver, every +0.1.0 release would be followed by a +0.0.1 for cleanup.
<solnic>
yep, boy scout rule etc
<xybre>
Cleanup, like, refactoring, and optimization after seeing it in the real world. (avoiding premature optimization and perfectionism)
<xybre>
Ie make it work, make it right, make it fast.
<solnic>
yep
<solnic>
these days I'm just much more focused on expressing what I want to achieve through TDD
<solnic>
I used to start with PoC/prototype code spikes without any tests
<solnic>
I no longer do that
<xybre>
I have a bad habit with perfectionism. So I'm trying to find good coping mechanisms. I feel much better about myself when I get things done rather than not. Nothing is perfect the first time, becasue, well, you haven't done it yet.
<solnic>
yeah
<solnic>
striving for perfection in programming is very dangerous anyway
<solnic>
first of all nothing will ever be as good as you would like it to be
<xybre>
I'd been doing the whole readme-driven-development thing, where I idealize my use cases and API, then I can implement the highest levels of functionality for the library so I can see when I've attained those goals, and then I can get down into the unit test layer and write real code.
<solnic>
yeah for me it always begins with a higher level "feature" test
<xybre>
I actually find that the more time I spend on the use cases and API the better everything goes afterwards.
<solnic>
then it's just a bunch of TDD cycles where I discover lower level individual units
<solnic>
btw re metrics I found that colors are much better feedback than numbers :)
<solnic>
numbers are too specific
<xybre>
I'm glad to not be color blind, but I agree.
<solnic>
it's easy to get trapped by chasing 100% coverage or some specific score in some metric
<solnic>
for instance at some point I found reek config to be a huge pain to maintain
<solnic>
it was simply getting in my way when I was in the middle of something
<solnic>
I also can't understand why would I want to set strict rules like "2 args max" or "2 LoC in a method max" etc
<solnic>
that will only push you to do premature refactorings
<solnic>
often leading you astray
<solnic>
at least that's my experience
<solnic>
for instance right now I know there are crappy parts in rom with code duplication or few cases of feature envy, I know I could refactor it now but at the same time I know that those things will be changed soon and I will get there in a natural way. I'm not going to just go ahead and refactor it because of metrics
<solnic>
and it reallly just boils down to maturity of a library, once I feel confident about the direction I will be refactoring smelly parts
<xybre>
I like to give generous range to metrics, so alarms only go off if things are really wrong. In the end most code ends up being much nicer than the broad metrics, but they're jsut there to let you know when things are getting out of hand.
<solnic>
if rom had rake ci failing because of metrics I would have to spend roughly a day or two refactoring...w/o any good reason
<solnic>
yeah I agree
<xybre>
Because the code is going to be removed anyway. Thats the problem with real projects, they go through crappy in-between times.
<xybre>
The difference is you want to make sure you're not *always* going throug ha crappy in-between-time.
<solnic>
for instance i feel uncomfortable when I have an object with more than 2 collaborators but that's often fine because at a given point in time I simply don't have a better idea how to split. Forcing myself to do that because of metric rules will be a bad idea. First I need to know what I want to do. Crucial part is the awareness of code smells not constant refactorings.
<solnic>
xybre: yeah full ack
<xybre>
I've noticed I do a lot of join/splitting of objects during development before their roles are clearly defined. 4 losely related methods in an object with a firm sense of identity is easier to handle to me than 4 objects with no sense of identity, 1 method each.
<xybre>
So my "metric" is as soon as I can identify a firm identity and place in the system I break it out.
<solnic>
yeah my brain works the same
<solnic>
when it comes to methods I usually need to see a bunch of private methods to get a clear idea of what should be extracted :)
<solnic>
re specific code smells I would really prefer to have a tool that would present a nice overview of your code base showing hot spots
<solnic>
something like codeclimate but with more stuff
<solnic>
which is pretty much reek with a nice presentation layer
<solnic>
it would be way easier for me to click through a nice UI than to mess around with yaml file all the time
<elskwid>
Please stop writing things I need to read.
<elskwid>
LOL
<solnic>
elskwid: no lol
<solnic>
you go and read
<xybre>
Establishing identity and use cases are aspects of novel pattern matching that people are good at but machines are not, so it can be counterproductive to focus on strict rules to the exclusion of the skills we've evolved to identify connections in emerging systems as humans.
* elskwid
grumbles
<solnic>
xybre: yeah
<xybre>
We should all be cyborgs, utilize our powerful pattern matching and creative abilities as humans and using machine logic to patch up the holes in our animal psychology.
<solnic>
this is exactly why I found metric feedback from some tools simply annoying
<solnic>
haha
<solnic>
no thanks I think I'm good
<xybre>
I mean metaphorically :)
<solnic>
OH OK ;)
robmiller has joined #rom-rb
<xybre>
Although I was working on a story involving something very similar.. I should get back to that at some point.
<mbj>
I have no time to read, but please note: I dont agree :P
<mbj>
I'll need to go offline before it becomes addictive, anoter type. Cya.
mbj has quit [Quit: leaving]
<xybre>
anoter type?
<solnic>
well I told mbj to try not to use metrics for a month (like, at all) and measure what he achieved and how it felt like
<solnic>
xybre: maybe he means "another time" I duno
<solnic>
dunno even
<solnic>
:)
<xybre>
Yeah I went to look up a german keyboard in case the keys were next to each other. :D
<solnic>
hah! :)
<solnic>
xybre: where are you from btw?
<xybre>
I live in the USA, I've moved around a lot in this country, currently in Chicago though.
<solnic>
xybre: ah Chicago, the second "country" of polish highlanders ;)
<xybre>
solnic: It's true! Haha. So many Poles around here.
<solnic>
yeah and the reason we still have visas ;(
<xybre>
I assume Poles come here because the weather is just as bad as Poland.
<solnic>
that's very likely ;)
<xybre>
RailsConf is here in the next couple of weeks, I hope to run into a bunch of people from all over.
<xybre>
In 1 week, rather
<solnic>
nice, didn't know it's in Chicago this year
<xybre>
I didn't either, actually, until a couple of days ago.