Disqus - Latest Comments for foca

Re: Rails 4.0 Sneak Peek: Queueing

Nicolas Sanguinetti — Wed, 12 Jun 2013 04:41:41 -0000

```
if Rails.env.test?
class Proc
alias_method :run, :call
end
end
```

Now you can use procs for testing.

Re: 7 Ways to Decompose Fat ActiveRecord Models

Nicolas Sanguinetti — Wed, 17 Oct 2012 12:50:38 -0000

Great article!

A couple nitpicks with the code examples:

* On `AbandonedTrialQuery#find_each` you want `@relation` instead of `relation`.
* On `FacebookCommentNotifier` you should probably inherit from `SimpleDelegator` (or similar) since that interface is too restrictive in the case where the comment doesn't save and goes into the `render "new"` branch.

Re: 2012 Rails Rumble

Nicolas Sanguinetti — Sat, 13 Oct 2012 01:39:24 -0000

Hell. Yes.

Re: Rails Rumble :: Just When You Thought You Were Out...

Nicolas Sanguinetti — Thu, 26 Jul 2012 11:05:49 -0000

Wheeeeeeeeeeeeeeee

Re: http://blog.railsrumble.com/blog/2012/04/23/delayed-but-not-forgotten

Nicolas Sanguinetti — Sun, 08 Jul 2012 19:05:09 -0000

@Brian Kung it's online.

Re: The three cancers in the Ruby community - Ruby treats women as objects

Nicolas Sanguinetti — Sun, 15 Apr 2012 22:23:33 -0000

Nope. If you only have one dimension, you have a straight line. An infinite, straight line. You can't "turn it on itself" so the ends meet.

And of course, since one dimension means only a straight line, there's no "right" (or "left"). You can't "turn right".

In order to "keep turning right" you need a plane, which is a two-dimensional entity.

Re: PHP: a fractal of bad design

Nicolas Sanguinetti — Tue, 10 Apr 2012 01:28:31 -0000

Awesome post! I'd love to see you do something similar for ruby, and python. Obviously for (at least) Python you won't be so negative, but I really would like to see what you see as "horrible" in both languages. In fact, make this a series and just cover any language you can get at when you have time to do it :)

Re: DCI Role Injection in Ruby :: Mike Pack Development

Nicolas Sanguinetti — Wed, 08 Feb 2012 17:23:06 -0000

So this it might not be "pure" DCI, but surely it's faster and the approach is similar:

Instead of defining modules with the Roles, define delegators.

class SomeRole < SimpleDelegator
  def initialize(obj)
    super obj.dup
  end

  def injected_method
  end
end

class SomeOtherRole < SimpleDelegator
  def initialize(obj)
    super obj.dup
  end

  def other_method_for_this_other_role
  end
end

I'm pretty sure the benchmarks for this will be much better, and you still keep small, focused objects around.

Re: How to add a Project to Railsonfire

Nicolas Sanguinetti — Tue, 31 Jan 2012 07:52:57 -0000

It'd be nice if you used ENV vars like heroku does. Providing a DATABASE_URL pointing to a database based on the Gemfile (as heroku does) would be nice. And generating a config/database.yml from that would be ideal.

If I can forget about configuring and it *just works* the same as heroku I'm a happier customer :)

Re: Mass assignment security shouldn't happen in the model: Jon Leighton

Nicolas Sanguinetti — Sun, 22 Jan 2012 16:48:05 -0000

Have you seen how Django does this? It defines objects for the "Forms" that handle validations. There's a ruby implementation of this for ruby called Bureaucrat: http://github.com/tizoc/bur...

Re: 5 things programmers preach but don’t practice

Nicolas Sanguinetti — Tue, 30 Aug 2011 17:04:12 -0000

Hosted CI is hard. It's something RunCodeRun experienced. It's something I figured before investing too much time or resources in FixTheBuild.com.

The best bet for Travis for closed source projects is, IMO, that they make it easy to install on your own architecture so you can configure build agents to fit your needs without much trouble.

Re: 2.5 Ways to Execute a Shell Command

Nicolas Sanguinetti — Thu, 04 Aug 2011 18:42:53 -0000

What's even *MORE* fun is that you can override ` for crazyness.

module OhMyGodDontDoThisAtHome
def `(string)
puts "HAHAHAHA TRICKED YOU!"
end
end

It's one of the best hidden "operators" of ruby :)

And for good reason. Seriously. Don't change the semantics of ``.

Re: If you gaze into nil, nil gazes also into you

Nicolas Sanguinetti — Thu, 04 Aug 2011 18:26:47 -0000

I like the NullObject pattern. I like the concept of the Maybe pattern, but I see two problems with your solution:

* You still need to know that #admin_of? might raise None::Unwrapped under certain conditions.

* Your Maybe class ends up with a huge interface to satisfy all possible clients. This is error prone in two ways:

a) what happens when class A returns a Maybe in which some_method? must return false for a null value, and class B returns a Maybe in which some_method? must return true for a null value (it's obviously a contrived example, and it's probably a smell about your design when methods with the same name have opposite semantics, but still…)

b) what happens when you refactor a method and forget to update the Maybe class because someone else defines the same method in Maybe (since all the tests run…), and later the semantics of that other class change, you update Maybe, and completely unrelated features/tests start failing for no apparent reason?

Both are easy to solve? Yes. But both wouldn't happen with an independent Null object for each case.

And your first example is easily solved by defining #admin_of? in terms of #member_of?

def admin_of?(project)
member_of?(project) && membership_for(project).admin?
end

(Of course, this won't apply for all cases, as this is a contrived example, and every nil situation looks like a nail when you have the NullObject hammer… but yeah.)

Re: If you gaze into nil, nil gazes also into you

Nicolas Sanguinetti — Thu, 04 Aug 2011 18:16:31 -0000

I like the NullObject pattern (the first solution he presents) for the general case.

I do want to point out, though (and this is why I reply to you,) that Hash also has a #fetch method that people should use over #[].

hash = { a: 1, b: 2, c: 3 }
hash[:d] #=> nil
hash.fetch(:d) #=> raises KeyError, ":d not found"
hash.fetch(:d, 0) #=> 0
hash.fetch(:d) { some_lazy_calculation } #=> the result of said calculation

This avoids the nil "problem" for hashes in 100% of the cases, yet for some reason people don't use Hash#fetch :(

(And, if for some reason, you do want to return a value or nil, then hash.fetch(:d, nil) makes it explicit that you might return nil)

Re: Why RubyGems Needs Loren Segal | James on Software

Nicolas Sanguinetti — Fri, 03 Jun 2011 16:06:45 -0000

+1 as well

Re: Edge Rails.info :: Reversible Migrations

Nicolas Sanguinetti — Sat, 07 May 2011 19:56:54 -0000

@Aditya Sanghi that's not hard to do with instance methods. And it requires less documentation:


    class RemoveTitleFromPosts < ActiveRecord::Migration
      def change
        remove_column :posts, :title
      rescue ActiveRecord::IrreversibleMigration
        # Just ignore this when reverting
      end
    end

And so on. Using if and all those things that ruby has :) There's no need to add DSLs that provide no benefit over simple code.

Re: We’re not like Yammer or Chatter, and we don’t want to be

Nicolas Sanguinetti — Thu, 10 Feb 2011 11:05:56 -0000

Oh, yeah, the layout is similar, and that's both reasonable and perfectly admissible. The color scheme (down to the colors for server notices and nick highlights!), and the typography, are the same, though, and I haven't seen a single screenshot of an "early day IRC client" with that particular scheme :)

Re: Blog of Ryan Bigg - Ubuntu, Ruby, RVM, Rails, and You

Nicolas Sanguinetti — Tue, 11 Jan 2011 22:53:35 -0000

BTW, regarding Puppet/Chef, you could use Vagrant to manage multiple development environments. It basically covers isolating the entire developer environment, and not just gems (think "app1 needs X version of external library" while "app2 needs Y version")

http://vagrantup.com/

Re: Love, hate, & tmux

Nicolas Sanguinetti — Sat, 11 Dec 2010 13:41:07 -0000

Oh. Ooooooooh. I owe you a keg of beer, I used to have this on my .vimrc:

nnoremap y "+y
vnoremap y "+y
nnoremap Y "+Y
vnoremap Y "+Y
nnoremap p "+p
vnoremap p "+p
nnoremap P "+P
vnoremap P "+P
nnoremap d "+d
vnoremap d "+d
nnoremap D "+D
vnoremap D "+D
nnoremap x "+x
vnoremap x "+x
nnoremap X "+X
vnoremap X "+X
nnoremap c "+c
vnoremap c "+c
nnoremap C "+C
vnoremap C "+C
vnoremap C "+C

This makes me a happy camper.

Re: Love, hate, & tmux

Nicolas Sanguinetti — Sat, 11 Dec 2010 13:37:02 -0000

<del>I have y, p, c, d, x, etc all remapped to use the + registry. Regrettably, that doesn't work inside tmux, but does work inside gnu screen, so I'm still using screen :)</del>

Uh, "set clipboard=unnamed" in your ~/.vimrc makes vim use the system registry by default.

Re: Debugging Rails Applications With ruby-debug - Intridea Blog

Nicolas Sanguinetti — Tue, 07 Dec 2010 17:29:43 -0000

I have a vim alias that inserts `require "ruby-debug"; debugger; ""`. That works in rails even if you don't start the server with `--debugger`, and also works in any other ruby project, so since I do a lot of non-rails ruby stuff, it ends up being more comfortable.

The "" at the end is because when the call to `debugger` is at the end of a method, you will get the debugger in the calling method. So, for example:

def a
"hello"
b
"world"
end

def b
x = 1
debugger
end

When you hit that debugger, the current line will be the one containing "world", inside the `a` method, and x will be out of scope. It's a contrived example, but useful :)

By default ruby-debug has this annoying habit of only showing you back the result of an expression (that isn't a debugger command) if you use the `p` command (so `p something` will be equivalent to doing `something` on irb).

In order to get around that, I add 'set autoeval' to my ~/.rdebugrc.

Also, adding 'set autolist' to that file will make it so that after command you run, it will show you where you are on the code (the current line and 5 lines before/after), which is immensely useful, specially when working with multiple breakpoints :)

And talking about multiple breakpoints, today a coworker told me about the 'b' (or 'break') command of ruby-debug, to set more breakpoints from inside the debugger. You can do 'b SomeClass#some_method' and you get an automatic breakpoint whenever that method is called. You can also do 'b some/file:11' to break on line 11 of some/file.

ruby-debug is probably the single most useful tool in my ruby development toolchain, right up there with rvm.

Re: http://blog.railsrumble.com/blog/2010/10/08/intridea-omniauth

Nicolas Sanguinetti — Fri, 08 Oct 2010 11:47:29 -0000

This is definitely interesting. Since we saw the announcement the other day we've been thinking about playing with OmniAuth.

For the rumble, though, the three devs in our team are used to Devise, and we all know that the Rumble is not the time to play with new stuff if you want to cross the finish line in 48 hours :)

So… We're undecided. But I'd definitely love to use it in other contexts!

Re: Class Methods Considered Annoying

Nicolas Sanguinetti — Tue, 14 Sep 2010 11:29:15 -0000

For the specific case of finders, I like Candy's approach: http://github.com/SFEley/candy

I haven't used it, though, so I'm not sure how annoying it gets, but TL;DR: You define an extra class for each of your models that handles the collection. So for the Person model you would also define People (which includes Candy::Collection). Person is blissfully unaware of finders and that sort of thing. People handles all that.

It feels much cleaner, even if a bit more verbose. Also, I keep typing People.all in the rails console because my mind tells me that I want a collection, so it probably maps better to *my* brain :P

Re: Class Methods Considered Annoying

Nicolas Sanguinetti — Tue, 14 Sep 2010 11:24:09 -0000

IMO, people who understand singleton methods should not define them on modules they plan to use as mixins.

What I do for this kind of thing (also ugly, but slightly less so): http://gist.github.com/579194

I don't think class methods are to be considered harmful. But they *ARE* definitely abused.

Re: blog dot voxdolo dot me | A Diatribe on Maintaining State

Nicolas Sanguinetti — Mon, 06 Sep 2010 09:20:49 -0000

I like it.

*But* except for very specific circumstances, I consider setters (and mutability in general), as A Bad Thing™. I agree that coding to an interface is, however, A Good Thing™.

Basically, if you look at it from the outside, you're now exposing state (and implementation details!) to your collaborators. Following on the (admittedly contrived) examples: why could I change a message's body? Maybe this is as simple as making #body= a protected method, thus not exposing it to clients.

I reckon I definitely think a lot more in terms of external APIs than internal APIs. That's something I have to get better at. But… I don't know, I'm just thinking out loud a bit.

Again, I like the concept, and maybe it's just the examples :)