mascip

• About: Perl, Javascript (AngularJS), Coffeescript, Firebase

Recent Actions

• Commented on "Functional core & Imperative shell" : OO design, and isolated tests without mocks
  Good point Samuel! Agreed. I think what people throw out at the moment, is mocking as a default for isolated testing: mocking most relationships in your tests, for the sake of isolation, is just wrong. Especially as isolated testing can...
• Commented on Functional core & Imperative shell: explanation with code
  I re-watched the videos, and realized that I forgot to mention something in this post: while the Functional core has the intelligence, the Shell has the State. For instance the Shell can keep track of where a cursor is on...
• Commented on "Functional core & Imperative shell" : OO design, and isolated tests without mocks
  Oh, I hadn't seen Ovid's previous comment. I'm in agreement with you on mocks Ovid. I think that learning to avoid mocks, while still testing lots of code in isolation, is what lead Gary to this idea of a functional...
• Commented on "Functional core & Imperative shell" : OO design, and isolated tests without mocks
  Explanation with examples, here: href="https://blogs.perl.org/users/mascip/2014/06/functional-core-imperative-shell-explanation-with-code.html...
• Posted Functional core & Imperative shell: explanation with code to mascip

  In my last article I introduced a design technique called Functional core and Imperative shell (let’s call it “FC&IS”). It enables to do…

• Commented on "Functional core & Imperative shell" : OO design, and isolated tests without mocks
  The answer lies in my Test Doubles link, where Martin Fowler explains that there are 4 kinds of test doubles: kinds of double: - Dummy objects are passed around but never actually used. Usually they are just used to fill...
• Commented on "Functional core & Imperative shell" : OO design, and isolated tests without mocks
  Cheers Toby. They could qualify then, but I would still prefer to manipulate immutable structures. Example coming tomorrow! (hopefully)...
• Commented on "Functional core & Imperative shell" : OO design, and isolated tests without mocks
  I will post a concrete example tomorrow: it's much easier to understand when you see it. And it's probably quite close to what lots of people (who put some care in their design) do already. My article is full of...
• Commented on "Functional core & Imperative shell" : OO design, and isolated tests without mocks
  I don't think MooX::Struct would work, because "your module can create a 'Point3D' struct, and some other module can too, and they won't interfere with each other". Value objects represent an interface between two classes; they must be defined in...
• Posted "Functional core & Imperative shell" : OO design, and isolated tests without mocks to mascip

  Following Ovid's Sick of being mocked by unit tests and the link to the discussion is TDD dead between Kent Beck and others, I found

• Commented on Immutability with Moo(se)
  I don't have a clear opinion about whether iterators should be mutable or immutable. But I would like tools to help me get some level of immutability, without me needing to work on it too hard. It would be nice...
• Commented on Immutability with Moo(se)
  Hi byterock :-) Apparently DBI delivers the Statement object in an immutable way, then. Apparently my goal is not clear. I've added a Post Scriptum to my original post to clarify it. Let me know if that worked....
• Commented on Immutability with Moo(se)
  I agree toby and dolmen, ultimately the goal is to avoid using mutable classes and methods. The problem is: We don't always realize that a method mutates an object. For instance here RJBS didn't realize that DateTime->add_duration() mutated the object....
• Commented on Immutability with Moo(se)
  Or can Sub::Trigger::Lock make a DateTime object immutable?? (throw an exception on method calls that would mutate the state)...
• Commented on Immutability with Moo(se)
  Oh, that's another way to go about it: making attributes read-only. But that means that you cannot use any object that's mutable. For instance, don't use DateTime objects as attributes because they are mutable. That might restrict us a bit....
• Posted Immutability with Moo(se) to mascip

  Would it be doable, to have a module to activate immutability with Moo(se)? Something like

  with MooX::Immutable;

  which would make all the objects from the class immutable.

• Commented on Prototypes and the call checker
  With Debuggit, calls debug statements don't end up in the compiled version of the program, when you turn DEBUG off: "any conditional based on the DEBUG constant will actually be removed during compile-time if the debugging level isn't high enough"...
• Commented on Extracting values from a list of (key, value) pairs
  Have you tried Var::Pairs, written by Damian Conway? It doesn't have a subroutine to extract all keys, but it's very god for loops: for my $next (pairs @array) { say $next->index, ' has the value ', $next->value; }...
• Commented on Three ways to introduce othogonal behavior: Aspects, Method modifiers, and Subroutine attributes
  Great, glad to help! I also learned a lot, writing this. Now I hope I understood the right things ;-) Please people, tell me what you think on the matter....
• Commented on Subroutine attributes: where and how to use them
  Cheers Reini. I added a note pointing to your comment, in the paragraph about Sub::Attribute....
• Posted Three ways to introduce othogonal behavior: Aspects, Method modifiers, and Subroutine attributes to mascip

  In my previous post I spoke about what Subroutine attributes are and how to use them. Here I compare them to other techniques for introducing orthogonal behaviors: Method modifiers and…

• Posted Subroutine attributes: where and how to use them to mascip

  I watched this video about Subroutine attributes, and I wrote myself a summary of what I learned. I thought I could share it.

• Commented on How to use the debugger with Moose
  Would the same thing be possible for STDERR output? When I encounter a bug while using Moose objects, it's sometimes a pain to find the one line that tells me where the problem comes from in my code. Any solution?...
• Commented on Planet Moose - October 2013
  MooX::PrivateAttributes is apparently recent branch of MooX::ProtectedAttributes, by the same author. Thanks for the news!...
• Commented on Perl5 in the browser update
  Very naive question Flavio: if i make a website with Perl5 (say, with the Dancer framework), do you think that some day i will just be able to compile it into Javascript with Perlito, and run it in a mobile...
• Commented on Perl Startups: Lokku/Nestoria
  Wow, i must say i'm impressed. I'm moving pretty soon, so i checked out Nestoria, to see what is available in my neighborhood (i want to stay in the same area). This website has bluffed me. It's pretty much what...
• Commented on Improved autobox-ing. I'm loving it :o)
  Thank you for the explanation and sorry for the mistake, i won't make it again. I've also read that you might make type checks disable-able, maybe with an environment variable. Thus enabling to develop with type-checks, without slowing down the...
• Commented on Type::Tiny rescues Moo
  Wow! Thank you Toby, I’ll start playing with it. It should also enable to clone mutable attribute# (like DateTime attributes), both at construction and for their accessor: all you need for proper immutability...
• Commented on Method::Signatures: where and when
  I should probably have written "in a package", rather than "in a Moo class"....
• Commented on Method::Signatures: where and when
  Hi Buddy, thanks a lot for Method::Signatures. One naive (unrealistic?) idea/request: Could there be any way for a user to tell in a Moo(se) class: “don’t do any type check for any subroutines of this class” ? Maybe in the...

Comment Threads

• Ovid commented on "Functional core & Imperative shell" : OO design, and isolated tests without mocks

  Other than an unreliable external service, why mock anything up? One argument I hear is "speed", but I'd rather have my tests correct than fast.

  Another argument I hear is "unit testing", but that's only because some people have an arbitrary definition of "unit" that somehow precludes fully exercising our code because we don't want it to talk to other code. I don't understand that.

  Yet another argument has been "this object is so hard to instantiate that we're just going to create a mock." I did that when I was a much younger programmer, not realizing that this is also known …

• Ovid commented on "Functional core & Imperative shell" : OO design, and isolated tests without mocks

  Also, I should point out that while your title says "without mocks", aren't "test doubles" just the same thing? I guess I should watch that presentation now :)

• Aristotle commented on "Functional core & Imperative shell" : OO design, and isolated tests without mocks

  Other than an unreliable external service, why mock anything up?

  Ovid, I linked you Gary Bernhardt’s Test Isolation Is About Avoiding Mocks in your own comments already – you really ought to read it. The (here deliberately over-summarised) punchline is that trying to test in isolation reveals invisible coupling. But really you ought to read the thing.

• Samuel Kaufman commented on "Functional core & Imperative shell" : OO design, and isolated tests without mocks

  What external service is not unreliable? Any web service your code speaks to is by nature unreliable.
  Say for example your app sends emails. You write tests that send real emails. That's great, until the SMTP server goes offline. You've only tested against the live server when it was working, so you have no coverage for this.
  Of course, if it was your SMTP server you could turn it off and see how your code responds.
  If it isn't in your c…

• Peter Martini commented on Prototypes and the call checker

  Zefram pointed me to http://search.cpan.org/dist/Debug-Show/lib/Debug/Show.pm, which is doing what I had in mind. Thanks!