Disqus - Latest Comments for charlysisto

Re: One more useful abstraction for Rails - My take on Form objects

charlysisto — Fri, 29 May 2015 11:18:51 -0000

I took a very similar path with my paramount gem (hardly a gem really just a very thin wrapper around Virtus & ActiveModel). Then in my controllers & views I use `@ar_model.form` to create and update. That way you extract validation, nested attributes, callback, params security... out of your business model in just one go. And only if necessary.

Re: The Reflux data flow model

charlysisto — Wed, 10 Dec 2014 16:37:36 -0000

It looked like the flux architecture made it mandatory for all actions (including server updates) to pass through the Action + Dispatcher gate. I was wondering if having the Stores being tide to the backend service & exposed directly to mutation could have any unwanted effect. Although it obviously doesn't brake the direction of the flow. On a higher abstraction I'm still trying to understand the role of the dispatcher in fb Flux and how Reflux manages to get rid of it... I'll dig more into it but any hint is welcome! thanx again

Re: The Reflux data flow model

charlysisto — Wed, 10 Dec 2014 12:09:32 -0000

very helpful thanx a lot & sooo much more sexier than the official flux. One question : is it ok that backend bypasses actions ? And another one : it seems the main role of the action is to break down the global bus into different channels - corresponding to more or less tot the different stores - is that right ?

Re: Challenges faced in a little larger Rails API project

charlysisto — Thu, 27 Nov 2014 06:15:48 -0000

Hi, just a quick note on how to apply scopes dynamically. The PdsasController make my teeth hurt having been through the pain of `scope this if params[:that]`... AcitveRelation is such a powerful abstraction, I find it bizarre that there's no 'Official Rails Way' to leverage the power it gives you in the controller. Anyway I created a gem for it : https://github.com/charly/s.... I use it everywhere in my admin sections and it's a blessing. I have search tool bars on all collection and I as a free bonus they're stateful.

Re: Search and filter Rails models without bloating your controller - Weissblog

charlysisto — Tue, 25 Feb 2014 15:41:20 -0000

You might want to have look at https://github.com/charly/s.... I also explain how you can combine it with ransack and nexter. I'll release a demo soon...

Re: When to use directives, controllers, or services in Angular JS

charlysisto — Fri, 20 Sep 2013 11:20:27 -0000

you nailed it.

Re: When to use directives, controllers, or services in Angular JS

charlysisto — Fri, 20 Sep 2013 06:21:52 -0000

yes :)

Re: When to use directives, controllers, or services in Angular JS

charlysisto — Fri, 20 Sep 2013 06:06:51 -0000

mmm, not quit sure yet... maybe we can agree on this : http://stackoverflow.com/qu.... That is angular.factory doesn't return the function you pass it but the return value of that function (which can be anything including another function or a new object).

angular.service on the other hand returns the instance of the function you pass it, ensuring it's always a new object (compared to factory it narrows down the possibilities and makes it more strict, which is good in many cases...)

So my question : is there any good reason ( a part from taste) you didn't write the function in a more conventional form with the 'this' keyword ? Because as it is written it looks like you want to use angular.factory (notice : sometimes prototype OO gives me headaches...)

Re: When to use directives, controllers, or services in Angular JS

charlysisto — Fri, 20 Sep 2013 05:17:14 -0000

Great article but I'm slightly confused with the notion of services being singletons "unlike factories". From what I understand service returns an instance of the function, where as factory returns the returned value of the function, but they **both always reference the same object** so I find it a little misleading to imply factories aren't singletons. Sorry for nitpicking, maybe there's something you meant I didn't get right.

Re: Models and Services in Angular

charlysisto — Tue, 30 Apr 2013 05:44:57 -0000

Actually since 1.1.3 (unstable release) you can use promises '$resource: expose promise based api via $then and $resolved'. Thanks for clarifying Joel's post. I enjoyed it but was extremely annoyed by the service/model confusion. His article was about architecting so terms and concepts are the most important aspects to grasp not just pedantic nuances. However he made a nice mea culpa and I hope we see more debates like this.

Re: How to use bundler instead of rvm gemsets - Rake Routes

charlysisto — Tue, 17 Apr 2012 16:37:59 -0000

http://ryan.mcgeary.org/201...
I suggest reading this (& comments) : It's a reference & I have been happily applying this bundle flow ever after.

Re: French court rules that it's illegally anticompetitive for Google to provide free maps API

charlysisto — Thu, 02 Feb 2012 08:37:07 -0000

Under french law you're presumed innocent

Re: http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/

charlysisto — Thu, 06 May 2010 10:05:22 -0000

Extremely helpful, wish there were more of these, domain modeling blog posts are too rare!

Re: Crazy, Heretical, and Awesome: The Way I Write Rails Apps | James on Software

charlysisto — Tue, 23 Mar 2010 09:52:13 -0000

I totally agree specially with the fileuploader example, having dealt with attachment_fu for years (built an image bank with it). Carrierwave makes so much more sense (images are handled in a seperate class). The state machine problem struck me as well, but never had the guts to try ruote.

Re: Why Riak should power your next Rails app - sean cribbs :: digital renaissance man

charlysisto — Mon, 08 Feb 2010 10:56:16 -0000

Thanks for this great post.

Had my nose a lot in mongo recentely and the limitations/possibilities of nosql (nojoins!)
http://groups.google.com/gr...

I would be very interested if you could explain a little more the link feature that other nosql solution don't seem to have and how you overcome its caveat : "The caveat of links is that they are inherently unidirectional, but this can be overcome with little difficulty in your application."

Re: Ruby Best Practices - Sexp for Rubyists

charlysisto — Fri, 05 Feb 2010 11:36:45 -0000

Everything you wanted to know about Sexp and didn't dare ask.
Ruby2ruby also does Sexp (with parsetree), very usefull to see inside the guts of a class (like methods generated by macros).

Re: Ruby Best Practices - Should I Tap that Hash? (Ruby 1.9 Style)

charlysisto — Fri, 07 Aug 2009 08:14:47 -0000

oh god you're right ! will shamefully update my blog. thanks!

Re: Ruby Best Practices - Should I Tap that Hash? (Ruby 1.9 Style)

charlysisto — Fri, 07 Aug 2009 07:15:35 -0000

"As for MyClass.new do |obj| ... end, the solution is *not* to use tap, but instead, to allow your initialize to yield the new object." -- i never meant that. Rather use it for what i'd call 'extra initializer methods' like this :

http://gist.github.com/163244

Most of my methods are 1 to 3 liners. My point is for "setup situps" having tap.new() at the start makes them immediately reveal their intention.

Re: Ruby Best Practices - Should I Tap that Hash? (Ruby 1.9 Style)

charlysisto — Thu, 06 Aug 2009 11:55:01 -0000

@Robert : I know that, read about ruby internals long time ago, sorry if my formulation could be somehow misleading. Just stressing the fact that new and initialize work hand in hand like tap could in a class method.

@sandal : I must admit i don't understand how/why you came to that conclusion. Probably missed the good argument in the comments ( i read quickly), open to hear your case :-). However isn't ruby all (hum a lot) about aesthetics ?

Re: Ruby Best Practices - Should I Tap that Hash? (Ruby 1.9 Style)

charlysisto — Thu, 06 Aug 2009 10:30:40 -0000

thanks for scratching my head ;-)

I agree on the fact both examples do the same. But it's common sense that whatever you put in the initialize definition it always returns the object when calling new on the class. So the block inside tap.new makes it very similar to that pattern/idiom. You see tap.new and you instantely know it's going to behave like find(:first), create or new... tap block doing the similar setup 'initializes' does.

It's opinionated for sure, just thought it's a better candidate for a ruby convention than using it on {}.

Re: Ruby Best Practices - Should I Tap that Hash? (Ruby 1.9 Style)

charlysisto — Thu, 06 Aug 2009 07:25:00 -0000

I think the reason why tap raises so much resistance here, is because hashes aren't really suited for it. It's much more legitimate combined with 'new' to initialize an object in a class method. I've put an explanation on my blog : http://ruby.simpase.com.