<mbj>
But I'm talking about an aggregated commit/pulse whatever.
<mbj>
So people see "this week 30 commits to rom gems".
<mbj>
Where 30 is the sum of all related repos.
<dkubb>
there's almost always some activity daily on some part of the ecosystem
<dkubb>
yeah, once you have the data aggregating it is easy
<mbj>
dkubb: So we need to setup axiom with fixed-base-relation adapters reading the web APIs of github ;)
<mbj>
+some caching.
<mbj>
dkubb: BTW will adamnatium backed by memoizable allow def foo; end; idempotent :foo syntax ?
<mbj>
memoize is probably the wrong name IMHO.
<dkubb>
mbj: not yet, but I would consider adding an alias
<dkubb>
mbj: you think adamantium should add the "idempotent" method?
<mbj>
dkubb: IMHO yes.
<dkubb>
I'd do that
<mbj>
I'd love to have a language allowing this:
<mbj>
idempotent foo # alternative to def
<mbj>
"bar"
<mbj>
end
<mbj>
command bar(baz) # alternative to def
<mbj>
@baz = baz
<mbj>
end
<dkubb>
in ruby 2.1 you'll be able to do: idempotent def foo
<mbj>
yeah, but the compiler does not know :(
<mbj>
The compiler does not know about what is a command method and what not.
<dkubb>
it would be nice to classify each method as command or query methods
<mbj>
yeah, thats my point
<mbj>
We talked about this already.
<dkubb>
a query method could disallow mutation
<dkubb>
even if the object was otherwise mutable
<mbj>
If the compiler would now a value expression was generated by an idempotent method call
<mbj>
dd
<mbj>
If the compiler would know a value is the result of an idempotent method call:
<mbj>
Cool optimizations could happen!
<dkubb>
my definition of a command method is a tiny bit looser though.. it must return self *or* a new instance of the same class that represents a state change
<mbj>
if the compiler would *know* foo.idempotent_method_call_without_args IS idempotent, he could introduce an lvar, executing the idempotent call once and use lvar as rhs of addition.
<mbj>
dkubb: In ruby the compiler would not know in advance
<mbj>
dkubb: But after the first item gets processed it could be known the rhs of addtion is idempotent.
floriankraft has joined #rom-rb
floriankraft is now known as florian_k
sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sferik has joined #rom-rb
<sferik>
hi all
<dkubb>
sferik: hi
<sferik>
just reading over the discussion about idem def foo
<sferik>
also: "I can aways replace it with a rom style web app framework later ;)"
<dkubb>
heh
<sferik>
are you guys planning to do a web framework once ROM is done?
<dkubb>
some of the guys are working on one for their own side projects
<sferik>
!
<sferik>
really?
<dkubb>
I don't know too much about it
<sferik>
is it OSS yet?
<sferik>
I really liked Merb, back in the day
<sferik>
something half-way between Sinatra and Rails
<sferik>
Rails is too heavy, Sinatra too weak
<sferik>
Merb felt just right to me
<dkubb>
I still feel like there's some improvement to be made in the way we do things
<sferik>
I know there’s Padrino or whatever, but I am slightly discouraged by that project
<sferik>
mostly because it didn’t seem to learn from any of Merb's mistakes
<sferik>
I saw them making the same mistakes
<dkubb>
it's basically rebuilding rails on top of a sinatra core, isn't it?
* sferik
nods
<dkubb>
as an outsider observer that's been my understanding, whether it's correct or not
<sferik>
Yeah, I’m also outside
<sferik>
never built a Padrino app
<sferik>
I still have a couple old merb apps that I maintain
<sferik>
they start up in a fraction of a second
<sferik>
and the code is really nice
<sferik>
Not perfect but nicer than most Rails apps I’ve worked on
<sferik>
it was really ahead of it’s time for building API servers
<sferik>
that was really the sweet spot for Merb
<florian_k>
i recently took a look at padrino... quite nice, in contrast to rails
<sferik>
florian_k, yeah? say more
<mbj>
sferik: What we started is FAR from padrino / merb.
<mbj>
sferik: You are a native german speaker? Just catch me an snusnu explaining it.
<mbj>
sferik: Its "differend".
<mbj>
sferik: Also its obviousely far from rails.
<florian_k>
as far as i could tell, it's basically sinatra with some sugar on the outside
<sferik>
mbj: Definitely not a German speaker yet
<sferik>
mbj: I am learning, slowly
<mbj>
sferik: Heh, so lets do it in english, once snusnu is back.
<mbj>
sferik: The idea is to plug lots of small unit tested parts into a chain. Resulting in a request processing pipeline.
<mbj>
sferik: Rather than inheriting controllers you instantiate them..
<sferik>
Seems good.
<mbj>
sferik: It is.
<mbj>
sferik: It enforces layering.
<dkubb>
I'm willing to try something new as an experiment
<mbj>
sferik: In the core you get https free domain.
<mbj>
sferik: s/https/http/
<sferik>
Is it built on Rack?
<mbj>
sferik: it abstracts away rack as fast as possible.
<dkubb>
mbj: some parts of the http protocol are quite nice. I wonder if it'll be ideal to completely insulate people from it
<mbj>
sferik: Rack is IMHO not a good representation for an http request / response cycle.
<mbj>
Its okay for the outer boundary.
<sferik>
Yeah, I agree
<dkubb>
its surprising to me how many app developers don't understand http caching or validation (like conditional GET, etc)
<mbj>
dkubb: Yeah. But for most crud + notifications stuff you dont actually need http to leak deep.
<mbj>
sferik: Yeah
<mbj>
sferik: I wrote two thiny libs abstracting away rack.
<dkubb>
I often leverage caching, but I suppose if I could define some caching rules I might be able to abstract it
<mbj>
sferik: *tiny
<sferik>
I like "thiny"
<sferik>
that's an awesome word
<mbj>
sferik: But unlike Rack::{Request,Response} I dont modify the rack_env hash.
<mbj>
And I dont give access to it again.
<mbj>
The rack request env hash is misused as a request global.
<mbj>
Each layer just tries to communicate with another layer using the request env hash as payload storage.
<mbj>
*in a traditional rack env
<mbj>
I dislike this.
<mbj>
sferik: if you are interested look into mbj/request and mbj/response
<mbj>
sferik: Also snusnu/cookie
<mbj>
sferik: And finally snusnu/substation (this one is the chain assembler, and executor).
<mbj>
sferik: But as always, we did this stuff for internal consumption.
<mbj>
sferik: So we are laking good documentations and howtos. But its build ROM-style.
<mbj>
Lots of small units, and full mutation coverage.
<dkubb>
what I would like is to work with resources and representations. something that understands caching, validation, and content negotiation. something optimized for building apis.
<mbj>
dkubb: Yeah, but you probably wanna do this on top of an real OO api, and NOT rack primitive hash ;)
<dkubb>
something that doesn't buffer requests and responses, but insteads allows me to process and emit them as streams.
<dkubb>
well yeah, I don't like the rack api too much
<mbj>
Just realize I need to write reades.
<mbj>
dkubb: Its IMHO okay for an outer boundary, but you should NOT leak its primitive details into your app.
<mbj>
sferik: just forge the stuff under mbj/request and mbj/response
<mbj>
sferik: Its lacking a readme. sorry.
<mbj>
sferik: Open an issue pls, I'll create one.
<mbj>
gotta go to sleep, cu
mbj has quit [Quit: leaving]
<sferik>
later
lgierth has quit [Ping timeout: 245 seconds]
lgierth has joined #rom-rb
<florian_k>
could it be that the currently released version for rom rb is a little bit broken? i started playing aroud with it this evening and the example did not relly run :/
<florian_k>
+a
<florian_k>
addendum: the errors i got came from an older version of axiom, to be exact
<dkubb>
ahh ok, I'll check it out
<dkubb>
one thing I wish travis had is a way to specify project dependencies
<dkubb>
so when I commit a change to one project, anything dependent on it could run it's own tests with the change
<florian_k>
mmmh, that'd be nice indeed
<dkubb>
I know we can do this with jenkins, but I don't really want to maintain a CI system right now