What a nice suggestion in moq.uservoice.com!

[Daniel Cazzulino]

http://moq.uservoice.com/pages/general/suggestions/122731-simplify-custom-matchers

Brian, what do you think about it?

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[Brian J. Cardiff]

I think it looks really nice!

Unfortunately it will add a public class to Moq (Kzu cares quite much about that :-P)

Additionally maybe we could remove the Attribute, and just look for a Matcher in the return type of the method called.

I would prefer to return a Predicate<T> ... but we need the implicit cast to achieve compilation.

Another alternative would be to pass the value to be matched at the end of the parameter list with a params keyword, but it will forbidden some nice matchers with explicit enumeration of allowed values.

What do others think about?

Brian J. Cardiff
bcardiff(?)gmail.com
.

[andreister]

>Additionally maybe we could remove the Attribute, and just look for a Matcher in the return type of the method called.

This would be great

On Feb 16, 1:45 pm, "Brian J. Cardiff" <bcard...@gmail.com> wrote:
> I think it looks really nice!Unfortunately it will add a public class to Moq

> (Kzu cares quite much about that :-P)
>
> Additionally maybe we could remove the Attribute, and just look for a
> Matcher in the return type of the method called.
> I would prefer to return a Predicate<T> ... but we need the implicit cast to
> achieve compilation.
> Another alternative would be to pass the value to be matched at the end of
> the parameter list with a params keyword, but it will forbidden some nice
> matchers with explicit enumeration of allowed values.
>
> What do others think about?
>
> Brian J. Cardiff
> bcardiff(?)gmail.com
> .
>
> On Mon, Feb 16, 2009 at 12:20 AM, Daniel Cazzulino <
>
> k...@clariusconsulting.net> wrote:
>

> >http://moq.uservoice.com/pages/general/suggestions/122731-simplify-cu...

[Daniel Cazzulino]

If we remove the attribute and just look for a Matcher return type, then public type count remains intact :). I like that, hehe.

I think this suggestion rocks and we should implement for v3 (i.e. this weekend :p).

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[Daniel Cazzulino]

working on this right now!!!!

this feature is going to ROCK

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[Matt Hamilton]

Since you're getting into screencasts, Kzu, it'd be nice to see a screencast explaining Matchers. I don't fully understand what they're for. Heck - a series detailing all the features in Moq would be awesome.

 

Matt

[Daniel Cazzulino]

Hehe... that would be nice, wouldn't it?

Added to my TODO list :)

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[andreister]

Mark it "planned" an moq.uservoice.com then! :)

Good luck!

On Feb 20, 4:11 am, Daniel Cazzulino <kzu....@gmail.com> wrote:
> working on this right now!!!!
>
> this feature is going to ROCK
>
> /kzu
>
> --
> Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1
> 425.329.3471
>

> On Thu, Feb 19, 2009 at 11:46 PM, Daniel Cazzulino <kzu....@gmail.com>wrote:
>
> > If we remove the attribute and just look for a Matcher return type, then
> > public type count remains intact :). I like that, hehe.
>
> > I think this suggestion rocks and we should implement for v3 (i.e. this
> > weekend :p).
>
> > /kzu
>
> > --
> > Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1
> > 425.329.3471
>

[andreister]

Matt, you may find some interesting stuff at http://code.google.com/p/mocking-frameworks-compare/

There's a scenario called ShoppingCartSample that contains a couple of
common tests (and covers matchers as well):
* Test1_MockedMethod - simply mock a method
* Test2_MockedEvent - mock an event invocation
* Test3_MockedProperty - simply mock a property
* Test4_MockedArgument - mock a method for a specific argument only
* Test5_PartialMocks - mock only some methods/properties, and call
original ones if they're not mocked
* Test6_RecursiveMocks - mock chains like "foo.Boo.Zoo.Goo()" without
having to mock the intermediate types.


Cheers,
Andrew

---------------------------------------------------
http://codevanced.net/ - Advanced solutions in .NET

On Feb 20, 4:16 am, Matt Hamilton <mabs...@madprops.org> wrote:
> Since you're getting into screencasts, Kzu, it'd be nice to see a screencast explaining Matchers. I don't fully understand what they're for. Heck - a series detailing all the features in Moq would be awesome.
>
> Matt
>
> From: Daniel Cazzulino
> Sent: Friday, February 20, 2009 2:11 PM
> To: moq...@googlegroups.com
> Subject: [Moq] Re: What a nice suggestion in moq.uservoice.com!
>
> working on this right now!!!!
>
> this feature is going to ROCK
>
> /kzu
>
> --
> Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471
>

> On Thu, Feb 19, 2009 at 11:46 PM, Daniel Cazzulino <kzu....@gmail.com> wrote:
>
>   If we remove the attribute and just look for a Matcher return type, then public type count remains intact :). I like that, hehe.
>
>   I think this suggestion rocks and we should implement for v3 (i.e. this weekend :p).
>
>   /kzu
>
>   --
>   Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471
>

[andreister]

Matt, you may find some interesting stuff at http://code.google.com/p/mocking-frameworks-compare/

There's a scenario called ShoppingCartSample that contains a couple of
common tests (and covers matchers as well):
* Test1_MockedMethod - simply mock a method
* Test2_MockedEvent - mock an event invocation
* Test3_MockedProperty - simply mock a property
* Test4_MockedArgument - mock a method for a specific argument only
* Test5_PartialMocks - mock only some methods/properties, and call
original ones if they're not mocked
* Test6_RecursiveMocks - mock chains like "foo.Boo.Zoo.Goo()" without
having to mock the intermediate types.


Cheers,
Andrew

---------------------------------------------------
http://codevanced.net/ - Advanced solutions in .NET


On Feb 20, 4:16 am, Matt Hamilton <mabs...@madprops.org> wrote:

> Since you're getting into screencasts, Kzu, it'd be nice to see a screencast explaining Matchers. I don't fully understand what they're for. Heck - a series detailing all the features in Moq would be awesome.
>
> Matt
>
> From: Daniel Cazzulino
> Sent: Friday, February 20, 2009 2:11 PM
> To: moq...@googlegroups.com
> Subject: [Moq] Re: What a nice suggestion in moq.uservoice.com!
>
> working on this right now!!!!
>
> this feature is going to ROCK
>
> /kzu
>
> --
> Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471
>

> On Thu, Feb 19, 2009 at 11:46 PM, Daniel Cazzulino <kzu....@gmail.com> wrote:
>
>   If we remove the attribute and just look for a Matcher return type, then public type count remains intact :). I like that, hehe.
>
>   I think this suggestion rocks and we should implement for v3 (i.e. this weekend :p).
>
>   /kzu
>
>   --
>   Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471
>

[andreister]

Mark it "planned" an moq.uservoice.com then! :)

Good luck!

On Feb 20, 4:11 am, Daniel Cazzulino <kzu....@gmail.com> wrote:

> working on this right now!!!!
>
> this feature is going to ROCK
>
> /kzu
>
> --
> Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1
> 425.329.3471
>

> On Thu, Feb 19, 2009 at 11:46 PM, Daniel Cazzulino <kzu....@gmail.com>wrote:
>
> > If we remove the attribute and just look for a Matcher return type, then
> > public type count remains intact :). I like that, hehe.
>
> > I think this suggestion rocks and we should implement for v3 (i.e. this
> > weekend :p).
>
> > /kzu
>
> > --
> > Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1
> > 425.329.3471
>

[andreister]

Mark it "planned" an moq.uservoice.com then! :)

Good luck!

On Feb 20, 4:11 am, Daniel Cazzulino <kzu....@gmail.com> wrote:

> working on this right now!!!!
>
> this feature is going to ROCK
>
> /kzu
>
> --
> Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1
> 425.329.3471
>

> On Thu, Feb 19, 2009 at 11:46 PM, Daniel Cazzulino <kzu....@gmail.com>wrote:
>
> > If we remove the attribute and just look for a Matcher return type, then
> > public type count remains intact :). I like that, hehe.
>
> > I think this suggestion rocks and we should implement for v3 (i.e. this
> > weekend :p).
>
> > /kzu
>
> > --
> > Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1
> > 425.329.3471
>

[andreister]

Matt, you may find some interesting stuff at http://code.google.com/p/mocking-frameworks-compare/

There's a scenario called ShoppingCartSample that contains a couple of
common tests (and covers matchers as well):
* Test1_MockedMethod - simply mock a method
* Test2_MockedEvent - mock an event invocation
* Test3_MockedProperty - simply mock a property
* Test4_MockedArgument - mock a method for a specific argument only
* Test5_PartialMocks - mock only some methods/properties, and call
original ones if they're not mocked
* Test6_RecursiveMocks - mock chains like "foo.Boo.Zoo.Goo()" without
having to mock the intermediate types.


Cheers,
Andrew

---------------------------------------------------
http://codevanced.net/ - Advanced solutions in .NET


On Feb 20, 4:16 am, Matt Hamilton <mabs...@madprops.org> wrote:

> Since you're getting into screencasts, Kzu, it'd be nice to see a screencast explaining Matchers. I don't fully understand what they're for. Heck - a series detailing all the features in Moq would be awesome.
>
> Matt
>
> From: Daniel Cazzulino
> Sent: Friday, February 20, 2009 2:11 PM
> To: moq...@googlegroups.com
> Subject: [Moq] Re: What a nice suggestion in moq.uservoice.com!
>
> working on this right now!!!!
>
> this feature is going to ROCK
>
> /kzu
>
> --
> Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471
>

> On Thu, Feb 19, 2009 at 11:46 PM, Daniel Cazzulino <kzu....@gmail.com> wrote:
>
>   If we remove the attribute and just look for a Matcher return type, then public type count remains intact :). I like that, hehe.
>
>   I think this suggestion rocks and we should implement for v3 (i.e. this weekend :p).
>
>   /kzu
>
>   --
>   Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471
>

[Daniel Cazzulino]

Marked as Started, and hit a hard wall AGAIN with this DAMN bug that is also the one that forced me (more than a year ago!) to impose the mock.Object crap on you :(

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=318122

Had almost forgotten about it. The implicit conversion on Match<T> will not work for anything but classes and (I think) primitive value types. Trying to get creative now on how to solve this (maybe generate a dynamicproxy class on the fly somehow?? :S:S:S). CRAP!

please please please VOTE for that issue! (although I'm afraid it's a bit late already :(((( )

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[andreister]

That bug's status is "Closed (Won't Fix)" :(

On Feb 20, 6:29 pm, Daniel Cazzulino <kzu....@gmail.com> wrote:
> Marked as Started, and hit a hard wall AGAIN with this DAMN bug that is also
> the one that forced me (more than a year ago!) to impose the mock.Object
> crap on you :(
>

> https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx...

>
> Had almost forgotten about it. The implicit conversion on Match<T> will not
> work for anything but classes and (I think) primitive value types. Trying to
> get creative now on how to solve this (maybe generate a dynamicproxy class
> on the fly somehow?? :S:S:S). CRAP!
>
> please please please VOTE for that issue! (although I'm afraid it's a bit
> late already :(((( )
>
> /kzu
>
> --
> Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1
> 425.329.3471
>

[Brad Stiles]

> the one that forced me (more than a year ago!) to impose the mock.Object
> crap on you :(

Just for the record, I *like* that "mock.Object crap". It's clear
which object one is working with.

Just so you know.

/bs

[Andrew Kazyrevich]

>"It's clear which object one is working with"

Why do you need that knowledge? What for?
Imagine they are removed: will it hamper the readability of your tests?

...Also I don't understand why some people prefix their mocked variables with "mock" - sounds pretty much like a reincarnation of the Hungarian notation :) With brief unit tests - 10-15 lines max - you don't need prefixes and (if only it was possible) don't need ".Object"

Just try with small tests and see, that stuff actually make tests *less* readable (imho).

[Brad Stiles]

> >"It's clear which object one is working with"

> Why do you need that knowledge? What for?

For clarity. In case I'm not the guy who has to make the next change
and breaks that test.

> Imagine they are removed: will it hamper the readability of your
tests?

Yes.

For me, 1 is clearer than 2

1.------------------
Mock<ISomething> mockedSomething = new Mock<ISomething>();

mockedSomething.Setup(...)
mockedSomething.Setup(...)

SomethingUser.Method(mockedSomething.object);

mockedSomething.Verify(...)

2.------------------
Mock<ISomething> mockedSomething = new Mock<ISomething>();

mockedSomething.Setup(...)
mockedSomething.Setup(...)

SomethingUser.Method(mockedSomething);

mockedSomething.Verify(...)

YMM,AOD,V

> Also I don't understand why some people prefix their mocked variables
> with "mock" -

Again, for clarity.

> Just try with small tests and see, that stuff actually make tests
*less* readable (imho).

I have, and it doesn't. For me, IMNECTHO.

/bs

[Daniel Cazzulino]

IMO, the .Object doesn't add value, and even myself every now and then forget to append it and get compilation errors.
It just adds friction.

In your case, if you prefix your objects with "mock" then you already know which object you're working with.

my 2c.

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[Daniel Cazzulino]

Ok, implemented this and will ship on v3 :)

Workaround: if the compiler complains about conversion to an interface type, just append .Convert() at the end of the matcher, like so:

public IEnumerable<Order> Contains(Order order)
{
  return new Match<IEnumerable<Order>>(orders => orders.Contains(order)).Convert();
}

sucks, but works :)

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[Brian J. Cardiff]

Since exposing the Match<T> as the return value type cause some problems with csc,

and in some scenarios .Convert() is necessary to be called,

why don't we hide Matcher type in a factory method?

this factory method should always call .Convert() before returning the value.

I didn't see the current implementation, so maybe I am missing something.

Brian J. Cardiff
bcardiff(?)gmail.com
.

[andreister]

Great work! Fantastic!!

Although looks like property matchers don't work - is there anything
preventing us from enabling that scenario?


I mean
===============================================
public Match<Iron> HotIron
{
get { return new Match<Iron>(x => x.IsHot); }
}
===============================================

instead of

===============================================
public Match<Iron> HotIron()
{
return new Match<Iron>(x => x.IsHot);
}
===============================================

The first one doesn't work for now.

Also I haven't yet come across any case where I had to explicitly
run .Convert() - are they about interfaces only?

Otherwise - brilliant stuff! Thanks and congratulations :)


PS. Said that, my Resharper screams bloody murder at the code as

return value == null || typeof(TValue).IsAssignableFrom(value.GetType
());

etc, from It.cs - as 'value' can be value type as well :)

On Feb 22, 2:03 pm, Daniel Cazzulino <kzu....@gmail.com> wrote:
> Ok, implemented this and will ship on v3 :)
>
> Workaround: if the compiler complains about conversion to an interface type,
> just append .Convert() at the end of the matcher, like so:
>
> public IEnumerable<Order> Contains(Order order)
> {
>   return new Match<IEnumerable<Order>>(orders =>
> orders.Contains(order)).Convert();
>
> }
>
> sucks, but works :)
>
> /kzu
>
> --
> Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1
> 425.329.3471
>

> On Fri, Feb 20, 2009 at 3:29 PM, Daniel Cazzulino <kzu....@gmail.com> wrote:
> > Marked as Started, and hit a hard wall AGAIN with this DAMN bug that is
> > also the one that forced me (more than a year ago!) to impose the
> > mock.Object crap on you :(
>

> >https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx...

>
> > Had almost forgotten about it. The implicit conversion on Match<T> will not
> > work for anything but classes and (I think) primitive value types. Trying to
> > get creative now on how to solve this (maybe generate a dynamicproxy class
> > on the fly somehow?? :S:S:S). CRAP!
>
> > please please please VOTE for that issue! (although I'm afraid it's a bit
> > late already :(((( )
>
> > /kzu
>
> > --
> > Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1
> > 425.329.3471
>

[Daniel Cazzulino]

Dunno why that would be a problem. Clearly, Resharper is a bit histerical:


        [Fact]
        public void ValueTypeSupportsNullObject()
        {
            var five = 5;
            var platform = PlatformID.Xbox;
            object fiveobj = five;
            object platformobj = platform;
            object foo = null;

            Assert.NotNull(fiveobj);
            Assert.NotNull(platformobj);
            Assert.Null(foo);
        }

Any value type that is casted to object will be non-null object, and that's perfectly fine ( and what the DP interception will do anyway).

I have implemented Brian's suggestion of making a static Create factory method (Match<Order>.Create(o => .... )), and property matchers :)). This is becoming seriously cool! hehe

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

[Matt Burton]

I've never used the Matcher functionality before - never learned what
those were, so I'm still trying to wrap my head around what you've
done here. I'm sure it's simple - maybe the terminology is throwing me
off. "Matcher" to me seems like something that would be used to verify
a call's parameters - as in "does this parameter match this predicate"
or something like that, but in the unit tests you're using them as
inputs to mock setups. Perhaps helping me with a concrete example from
my domain would help:

Here I need to verify that my code invoked the "Send" method on the
bus mock, and the "SomethingCreated" message that was the parameter to
the method had a CorrelationId that matched a known correlation id
from my test body.

bus.Verify(x => x.Send(It.Is<SomethingCreated>(y => y.CorrelationId ==
correlationId)));

Can I / should I use a matcher to make this verification easier to
understand and/or have less code to write? It seems as though
something like a matcher would be helpful to do assertions on complex
object types - i.e. do properties 1, 2, and 3 equal A, B, and C - is
that a correct statement or is there a better way to do that, even?
Maybe it's the cold medication or maybe I'm just dense right
now...help me understand, people. :)

Thanks,
Matt

[andreister]

Now instead of

=============================================

bus.Verify(x => x.Send(It.Is<SomethingCreated>(y => y.CorrelationId ==
correlationId)));

=============================================

of you can use a somewhat less verbose
=============================================
bus.Verify(x => x.Send(Correlation(correlationId)));
...

public Match<SomethingCreated> Correlation(int id)
{
return new Match<SomethingCreated>(x => x.CorrelationId == id);
}
=============================================


Hope this helps,
Andrew

On Feb 23, 7:51 am, Matt Burton <matt.bur...@gmail.com> wrote:
> I've never used the Matcher functionality before - never learned what
> those were, so I'm still trying to wrap my head around what you've
> done here. I'm sure it's simple - maybe the terminology is throwing me
> off. "Matcher" to me seems like something that would be used to verify
> a call's parameters - as in "does this parameter match this predicate"
> or something like that, but in the unit tests you're using them as
> inputs to mock setups. Perhaps helping me with a concrete example from
> my domain would help:
>
> Here I need to verify that my code invoked the "Send" method on the
> bus mock, and the "SomethingCreated" message that was the parameter to
> the method had a CorrelationId that matched a known correlation id
> from my test body.
>
> bus.Verify(x => x.Send(It.Is<SomethingCreated>(y => y.CorrelationId ==
> correlationId)));
>
> Can I / should I use a matcher to make this verification easier to
> understand and/or have less code to write? It seems as though
> something like a matcher would be helpful to do assertions on complex
> object types - i.e. do properties 1, 2, and 3 equal A, B, and C - is
> that a correct statement or is there a better way to do that, even?
> Maybe it's the cold medication or maybe I'm just dense right
> now...help me understand, people. :)
>
> Thanks,
> Matt
>

> On Sun, Feb 22, 2009 at 7:56 PM, Daniel Cazzulino <kzu....@gmail.com> wrote:
> > Dunno why that would be a problem. Clearly, Resharper is a bit histerical:
>
> >         [Fact]
> >         public void ValueTypeSupportsNullObject()
> >         {
> >             var five = 5;
> >             var platform = PlatformID.Xbox;
> >             object fiveobj = five;
> >             object platformobj = platform;
> >             object foo = null;
>
> >             Assert.NotNull(fiveobj);
> >             Assert.NotNull(platformobj);
> >             Assert.Null(foo);
> >         }
>
> > Any value type that is casted to object will be non-null object, and that's
> > perfectly fine ( and what the DP interception will do anyway).
>
> > I have implemented Brian's suggestion of making a static Create factory
> > method (Match<Order>.Create(o => .... )), and property matchers :)). This is
> > becoming seriously cool! hehe
>
> > /kzu
>
> > --
> > Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1
> > 425.329.3471
>

[Lucas Meijer]

On Mon, Feb 23, 2009 at 9:14 AM, andreister <andre...@gmail.com> wrote:

Now instead of

=============================================

bus.Verify(x => x.Send(It.Is<SomethingCreated>(y => y.CorrelationId ==
correlationId)));

=============================================

of you can use a somewhat less verbose
=============================================
bus.Verify(x => x.Send(Correlation(correlationId)));
...

public Match<SomethingCreated> Correlation(int id)
{
 return new Match<SomethingCreated>(x => x.CorrelationId == id);
}
=============================================


Hope this helps,

I often find myself wanting to verify a certain method being called. Often the method

has many arguments, but I'm only interested in one.  Is there a way to write it more

compact than:

mock.Verify(x => x.Send(It.IsAny<MyArg1Type>(), It.IsAny<MyArg2Type>(), It.IsAny<MyArg3Type>(), It.Is<MyArg4Type>( (MyArg4Type arg) => arg.Something == 14) ) );

?

Bye, Lucas 

[Brian J. Cardiff]

you could create a shourtcut for It.IsAny<T>();

For example with

static class A
{
    public static String String
    {
          get { return Match<String>.Create(s => true); } /* I would check for non null arguments :-) */
    }
}

you could write

mock.Verify(x => x.Foo(A.String, A.String));

but you would need one for each type (until C# 6.0 maybe :-P with return type inference and generic properties).

Brian J. Cardiff
bcardiff(?)gmail.com
.

[Brian J. Cardiff]

I have updated my original post about MatcherAttribute.

Here is the new version http://weblogs.manas.com.ar/bcardiff/2009/02/reimproved-argument-matchers-in-moq/

Brian J. Cardiff
bcardiff(?)gmail.com
.

[Lucas Meijer]

On Mon, Feb 23, 2009 at 2:03 PM, Brian J. Cardiff <bcar...@gmail.com> wrote:

mock.Verify(x => x.Foo(A.String, A.String));

but you would need one for each type (until C# 6.0 maybe :-P with return type inference and generic properties).

Thanks Brian.  That's already quite a bit better than the It.IsAny<>()'s.

too bad there is no return type type inference yet.

I wonder if there's another way to get the verbosity down. It feels like it should be possible,

since all information is available, but I guess we really need return type inference in order to

get something like this to work.

Bye, Lucas

 

--
-- Lucas Meijer Consulting | Unity3D & GameDev | lu...@lucasmeijer.com
-- Blog: http://lucasmeijer.com/blog
-- Twitter: lucasmeijer