<mbj>
There is a lazy default module, just need to find how to trigger it.
<dbussink>
hmm
<mbj>
With lazy default you could easily substract the attribute names from already assigned ivars into the set of the "not explicitly defined attributes".
<dbussink>
yeah, that could work
<dbussink>
but still feels a bit whacky
<dbussink>
going to compare with some other options :)
<dbussink>
but the idea for the futures is basically to enable parallization
<dbussink>
so image you'd do model = API::SomeModel.get(1)
<dbussink>
relation = model.relations
<mbj>
future = API::SomeModel.get(1) # ;)
<dbussink>
that model object basically acts as a future
<mbj>
okay
<dbussink>
so the idea is that model.relations only actually needs the model id
<dbussink>
so the 1 value
<dbussink>
so it can already start the two queries at (almost) the same time
<dbussink>
so it doesn\t have to wait for the SomeModel.get() to finish to start the relations api call
<dbussink>
so instead of 2 serial api calls, it can do two parallel
<mbj>
Why not something like:
<dbussink>
in a view one might do model.name and relations.each {}
<dbussink>
btw, this is the current api that people use that i don't want to break :)
<dbussink>
so basically parallelizing the library end user api without having to change how they use it
<mbj>
dbussink: Yeah so "outside" the model-future the calls are synchronous.
<mbj>
dbussink: Where inside they are optimized to do async / parallel work.
<dbussink>
mbj: that's basically why they work like a future
<mbj>
dbussink: model#some_property_that_needs_to_be_loaded will block while the inner (maybe parallel workings) of the object create the return value.
<mbj>
dbussink: Got it.
<dbussink>
if i'd do model.id it would return 1 instantly
<dbussink>
without having to wait for the api call to finish
<mbj>
dbussink: So why virtus?
<dbussink>
that's currently used to model the api attribute wise
<dbussink>
coercions etc. from the original json / xml representations
<dbussink>
to get integers, dates etc.
<mbj>
dbussink: I'd not enrich a virtus object with that future stuff. To much SRP violation.
<mbj>
You already thougth about an API compatible proxy.
<mbj>
Okay, I get the problem domain. And I'd *love* to spike something out.
<dbussink>
that's exactly why i'm introducing a wrapper around it
<mbj>
But I have to go back to more boring commercial stuff.
<dbussink>
but i think i can do this differently
<dbussink>
hehe, this is my commercial stuff atm :P
<dbussink>
anyway
<dbussink>
thanks for the discussion, i think it helped :)
<mbj>
dbussink: Its always good to be forced to explain ;)
<dbussink>
yeah
<mbj>
dbussink: Lets talk later this day, I'll spike something after 18:00.
<dbussink>
rubber ducking ftw :)
<mbj>
dbussink: Just for fun.
<dbussink>
mbj: nah, no need, don't feel like you have to :)
<mbj>
dbussink: Not to help you, to HELP ME ;)
<dbussink>
hehe
<dbussink>
mbj: if you end up making something, let me know :)
<dbussink>
curious what you would come up with :)
<mbj>
dbussink: It will be heavily relying on adamantium / memoizable while delegating writes to mutable stuff intern.
<mbj>
the facade/future will manage parallelism.
<mbj>
I have a pretty sharp idea. (And I thougt about gemifing something like this already some time ago).
<mbj>
Lets hope the idea turns out to be usefull.
<mbj>
Rule of thumb: Parlallelism is much more easy with immutable datastructures.
<dbussink>
oh yeah, definitely true
<dbussink>
they are basically immutable anyway
<dbussink>
more like partial is the problem
snusnu has joined #rom-rb
<dbussink>
mbj: although they actually can be modified and saved over a different api
<dbussink>
but that can't happen before it's completely retrieved
<dbussink>
so any modification always waits for the future anyway
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 240 seconds]
snusnu has quit [Quit: Leaving.]
postmodern has quit [Quit: Leaving]
cored has joined #rom-rb
cored has quit [Changing host]
cored has joined #rom-rb
snusnu has joined #rom-rb
jgaskins has joined #rom-rb
mkristian has joined #rom-rb
bf4 has joined #rom-rb
breakingthings has joined #rom-rb
bf4 has quit [Read error: Operation timed out]
bf4 has joined #rom-rb
snusnu has quit [Quit: Leaving.]
bf4 has quit [Ping timeout: 240 seconds]
CraigBuchek has joined #rom-rb
lfox has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 250 seconds]
lfox has quit [Ping timeout: 245 seconds]
bf4 has joined #rom-rb
snusnu has joined #rom-rb
mkristian_ has joined #rom-rb
mkristian has quit [Ping timeout: 245 seconds]
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
mkristian__ has joined #rom-rb
mkristian_ has quit [Ping timeout: 264 seconds]
CraigBuchek has quit [Quit: Leaving.]
skade has joined #rom-rb
skade has quit [Client Quit]
onewheelskyward has quit [Ping timeout: 246 seconds]
onewheelskyward has joined #rom-rb
vsorlov has joined #rom-rb
onewheelskyward has quit [Ping timeout: 246 seconds]
<mbj>
I'd like to continue my "mbj" existance on gittip.
<mbj>
It reads like my mbj account will be transformed into rom once I hit the "we are a team" button?!
<mbj>
snusnu: whelp!
<mbj>
Or I login via twitter and our rom_rb handle to create the team account? I'd like to have it linked with the gh org.
<snusnu>
mbj: the way i understand gittip teams is that they're created from a specific account, that essentially becomes the team lead .. all other team members can decide on how much they take out each week, and what's left, goes to the team lead .. so i'm not surprised that you need to start with a single person, turn that into a team, and gradually invite others to the team
<snusnu>
mbj: i might be wrong of course
<mbj>
snusnu: So lets create an account bound to the @rom_rb handle on twitter?
<snusnu>
mbj: nah i guess that's not the way it works
<mbj>
snusnu: So my "mbj" would go away if I create a team?
<mbj>
Feels stupid.
<snusnu>
mbj: you can only direct gifts to specific people, no artifical entity, iirc
<snusnu>
mbj: no, it wouldn't
<mbj>
OHA.
<mbj>
snusnu: I'd prefer all the gifts would be shared among team members.
<mbj>
snusnu: Equally.
<snusnu>
mbj: you'd get what's left over after rom team members took their cut, plus you can still get gifts directed at you specifically
<snusnu>
mbj: that's not gittip's philosophy
<mbj>
snusnu: mhh, I think this sheme results in to much tracking.
<snusnu>
mbj: it's philosophy is that everyone takes out as much as he/she thinks is ok
<mbj>
snusnu: If we wanted to share equally.
<snusnu>
mbj: we can do that
<mbj>
snusnu: No we cant.
<mbj>
?
<mbj>
As I said, I'm to stupid for gittip teams.
<snusnu>
mbj: we'd have to talk to each other, see how much the team gets each week, and then each take out exactly the equal split
<snusnu>
it's a manual process tho
<mbj>
snusnu: But the team lead cannot take out anything.
<snusnu>
mbj: the team feature is kinda clever imo, it's definitely a "new" way of looking at this issue tho
<snusnu>
mbj: nope he/she can't .. he/she gets what's left
<snusnu>
after the others took out
<mbj>
snusnu: If all non-lead members take out n, we'd all the time have to adjust "N"
<mbj>
snusnu: To make sure the team lead gets an equal N.
<snusnu>
yeah, if we want equal split, there's currently no other way than to "enforce" that manually
<mbj>
snusnu: So if we create an artificial team lead and all of us are taking out a big number.
<snusnu>
call it a bug or a feature, i dunno, i kinda like it
<mbj>
snusnu: The lead would never get anything.
<mbj>
snusnu: Get the hack?
<snusnu>
i guess i get it, but i'm not sure if it would be that wise
<mbj>
snusnu: if an artificial lead gets something we can use it for paying domains ;)
<snusnu>
in the end tho, that artificial lead would need to be a real person tho anyway, at least some entity backed with an account :p
<snusnu>
also, tbh, i don't see the point in equal split
<snusnu>
gittip is kinda experimenting with this, trying to see if it leads to "fair" split
<snusnu>
i guess it can lead to that
<mbj>
snusnu: Its fair and we dont need to adjust it.
<mbj>
snusnu: I dislike to rethink N all week.
<snusnu>
it is not necessarily fair tho
<snusnu>
fair depends on what we agree to be fair
<mbj>
snusnu: I dislike accounting in that way.
<mbj>
snusnu: All the time thinking "What is fair this week"
<snusnu>
fwiw i fully agree that equal split might be a good strategy, but what gittip currently supports, is more flexible
<snusnu>
hehe, well, gittip's different, it makes you think different
<mbj>
snusnu: I'd dislike to rething "the fairness of the week". I just wanna code ;)
<mbj>
snusnu: *rethink
<snusnu>
so, you do 100commits a week, i do none, is it fair if the split is equal? (remember, those payments arrive *weekly*
<mbj>
snusnu: Over the year it would be fair.
<mbj>
snusnu: Just to strait even split, chances are high over the year nobody really misses anything.
<mbj>
dbussink: I'm totally okay with doing more than average commits but receive a fair split.
<mbj>
dbussink: sorry, tab error
<snusnu>
dunno, i see how this is pragmatic, but tbh i'd like gittip's take on it too
<snusnu>
take out as much as you think deserve, this week
<mbj>
snusnu: I just dont wanna "waste" my time with calculations / communications each week.
<snusnu>
for that to really happen, people would need to actually tip us tho
<snusnu>
:p
<mbj>
snusnu: heh
<mbj>
snusnu: So who wants to be team lead?
<snusnu>
i don't care tbh
<snusnu>
and that's the point
<snusnu>
there's probably also nothing inherently wrong with having an artificial lead, connected to an account the team agrees that it will be distributed in certain ways (like, equally, after some time of collecting, or for maintenance purely)
<snusnu>
in any case, i'd say that actually *making* a team on gittip should probably be done with all of us accepting the rules/consequences
<mbj>
snusnu: yeah
<snusnu>
that reminds me, i wanted to listen to Chad's recent open discussion with heinemeier
<dkubb>
mbj: ok, got it. I didn't know about the team feature
<mbj>
dkubb: What would be *YOUR* preffered gift split system? (If therer where any gits to share ; )
<mbj>
*gifts
<mbj>
dkubb: BTW did I mentioned I ironed out all mutant issues that could be classified as "bug" ? And released 0.3.0.rc4
<mbj>
dkubb: I think 0.3 could be released soon. Than 0.4 will feature more flexible kill strategy selection (and focus here).
kapowaz_ has joined #rom-rb
<dkubb>
mbj: nice. I think I saw the mutant update. I'll release the adamanitum with memoizable changes shortly
<dkubb>
mbj: It does seem like it could be time consuming if we have to decide every week how much to take out, it would be easier to just distribute it evenly between the currently active members
<dkubb>
mbj: if someone falls behind on contributions then they should either request that their share be redistributed to the remaining active people; or the remaining active people can decide that
<dkubb>
mbj: over the course of a year it'll work out close enough
<dkubb>
OT, but I find consensus algorithms to be really interesting. here's one called Raft which seeks to be more easily understabale than Paxos: https://www.youtube.com/watch?v=YbZ3zDzDnrw
<mbj>
dkubb: Yeah, just break mutant self zombificiation, than I have a good reason to fix ;)
<mbj>
dkubb: Very busy commercially :(
<dkubb>
mbj: I understand
namelessjon has joined #rom-rb
<namelessjon>
Hey mbj
<mbj>
namelessjon: hi
<mbj>
namelessjon: I'd *love* to talk now about why I think rack-* is NOT a good interface. Why it needs to be improved and what I've already done and discussed (mostly with snusnu).
<mbj>
namelessjon: But I'm very busy commercially!
<mbj>
namelessjon: See mbj/request and mbj/response on github, also snusnu/cookie and later snusnu/substation. It might be uneasy to get the gist of our plannings, but I cannot do more than give you pointers to stuff that I think is "maybe part" of the problem solution ;)
<namelessjon>
It was mostly about the env thing. And not seeing the conceptual difference between that, and say, a rom env (though organisation in the hash could be better, if that's what you mean by global?)
<mbj>
namelessjon: request global.
<mbj>
namelessjon: Think about most (all?) frameworks / libs are build on top of rack.
<mbj>
namelessjon: Basically "Everywhere" you have access to the original request env. Which is a mutable hash.
<mbj>
namelessjon: Wich is a big source of "hacks" that *always* go wrong when the app grows.
<mbj>
namelessjon: Most of the "parser" state is also accumultated in this mutable hash.
<mbj>
namelessjon: See how rack (the library!) implements Rack::Request#params, it stores the "parsed" value inside this hash.
<mbj>
namelessjon: Its a manifestation of a smell. A smell I call 'inline signalling'. The whole rack request env hash is just a big smell. IMHO.
<mbj>
I refactored away su much crappy code over the years that used the env hash for "cross layer signalling".
<mbj>
Resulting in security issues, stability problems and indeterministic behavior. (Especially under threading).
<mbj>
IMHO the representation of an http request *MUST* have an immutable interface, to eliminate a whole class of bugs.
<mbj>
namelessjon: I call the rack request env hash a "request global" to illustrate the weaknesses this design has.
<mbj>
</done-my-rant> ;)
<namelessjon>
Okay, but what about the other things that the env provides (e.g. error stream, a rom-rb environment too, maybe?).
<mbj>
namelessjon: a rom-rb will only/mostly expose a immutable interface. If you can mutate state it will be well defined/constrained and thread-safe. We'll not have an {} as our main primitive ;)
<namelessjon>
mbj: Hmmm. Not sure I'm entirely convinced, but thanks for taking the time to expand on it. I will mull it over some more.
avdi_ has quit []
avdi_ has joined #rom-rb
<mbj>
namelessjon: Yeah. Feel free to bring up your thoughts. Talking to someone who does NOT share my opinion is far more interesting than an echo-chamber ;)
<mbj>
namelessjon: Even if both communication partners will not convince the other in any way - Its still very interesting ;)
<namelessjon>
mbj: When I have something more coherrent than "That doesn't seem to be quite right", I'll happily talk :)
<mbj>
namelessjon: ;)
<mbj>
namelessjon: I'm a native resident in this channel, just come in and help me sharp my understanding.
<namelessjon>
mbj: I know where to find you ;)
<mbj>
namelessjon: I need to start writing my thoughts down. All the time I talk to someone about such stuff I feel I miss stuff I argued with the iteration before.
snusnu has quit [Quit: Leaving.]
jordanyee has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<namelessjon>
mbj: It would be interesting to see them more long-form.
<dkubb>
yeah, that'll be the most fair. it'll be up to the team to monitor this and for individuals to say "I didn't do too much last month, lemme remove myself from the pool for a bit until I catch up"
<dkubb>
which is just as it should be. I trust everyone to monitor themselves
<mbj>
dkubb: exactly
<mbj>
dkubb: Dislike to think each week about "Do I need to pull more or less to make sure its even".
<mbj>
dkubb: I'd also be okay to just "let all stay in the pool even for month with 0 commits" - Over the year it will be even.
snusnu1 has quit [Quit: Leaving.]
snusnu has joined #rom-rb
<dkubb>
mbj: yeah, I'd probably only expect someone to leave if they were going to take a few months off or whatever (or leave the project if that is what they wanted to do)
breakingthings has joined #rom-rb
CraigBuchek has quit [Quit: Leaving.]
onewheelskyward has quit [Ping timeout: 245 seconds]
onewheelskyward has joined #rom-rb
postmodern has joined #rom-rb
vsorlov has quit [Ping timeout: 250 seconds]
onewheelskyward has quit [Quit: ZNC - http://znc.in]
onewheelskyward has joined #rom-rb
onewheelskyward has quit [Client Quit]
snusnu has quit [Quit: Leaving.]
onewheelskyward has joined #rom-rb
snusnu1 has joined #rom-rb
jgaskins has quit [Quit: This computer has gone to sleep]