This Week I Learned 2019 - Week 12

Last week post or something else instead.

What else I've learned this week? On ornamental fish culture, finished up topic 7 on larval rearing on Angelfish, Yellowtail Damselfish, and Clownfish. This followed by topic 8 on water filtering system. The paper of the week is on the study of different foods on efficiency of spawning in Betta sp. Concluding this week, Test::Mock::Simple is the Perl module we reviewed this week.

Is it healthy to eat three or more eggs per week? (via SD) Regardless what, always stick to the common sense advice, everything in moderation, more fruits, vegetables, fiber, whole grains, and cut down on sugar, fat, and processed food. Dietary studies or nutritional researches (do check who is funding the research, as they said, follow the money) always gave conflicting recommendations and hard to do well and there are many factors (other foods or age) involved. Again, moderation food intake, exercises, and sleep and always the good baseline for healthy life. Pay attention and listen to your body.

What is the theory about upgrading stuff? A well-said (see quote below) insight on upgrading your computer hardware.
"There’s a lot of research that shows that actually if you want to increase your happiness by spending money then the only way to do that really is by removing salient negatives rather than by adding additional positives."
Instead of getting the latest greatest, upgrade when what you currently have is really inadequate to solve your problem. For example, getting a 7-seater car (used is preferable) when the 5-seater is incapable of handling a family size of 6 people or 7 people if you includes the pet dog.

What is the craft of self-teaching? There is one trendy occurrence within Github these day. Lots of interesting books published through Github from developer from China. One of these book is the "The Craft of Self-teaching", an interactive book published through Jupyter on self-learning and Python. Numerous technical publications have been hidden behind the Great Wall of China in numerous forums, BBS and other and we're now slowly see some these being released out through the crack of the wall.

Which crypto exchanges companies you should be focusing on in MY? These 22 companies which are currently seeking regulatory approval.

What is the suitable way to do OO in Perl? Moo for all rounded usage, Class::Tiny for less dependencies, and lastly Object::Simple if you really don't need any inheritances and simple default. However, if you really want to roll your own with default values as shown below. 'name' is the default value which can be overridden with value in `@_` of the same key.
sub new {
    my $class = shift;
    return bless { name => "Jane", data => {}, @_ }, $class;

Stuck with a machine without Perl interpreter? Use Perl Banjo. Useful for quick Perl script but unfortunately not all modules available, only the default list.

Perl Module(s) Of The Week - 2019 Week 12 - Test::Mock::Simple

If you're in software development, should you apply Test-drive Development (TDD) into you development life cycle? Depends. There are many school of thoughts. Some argue that TDD is only for those with luxury of time and budget, while other contest that it should be used only for critical part, and certain group advocate that we should satisfy the full code coverage. In hindsight, I would recommend it, to a certain extend. But for integration testing with third parties API and your're the library producer. TDD is compulsory to ensure consistency.

On side note, while looking into TDD, I've learned that there are two schools of TDD, the Classicist vs. Mockist or Detroit vs. London. Based on the definition, my style of TDD belongs to the old school, Detroit-based or state-based TDD.

This leads us to our discussion this week, a simple module of mock testing, Test::Mock::Simple. While there are numerous test modules available in CPAN, as the module name implies, this is one of the simplest one available.

As usual, installation for the module.
$ cpanm Test::Mock::Simple

Let's go straight to an example as shown below. The script `` made a simple HTTP request to an API endpoint to obtain its content.
use strictures 2;
use REST::Client;

my $client = REST::Client->new;
print $client->responseContent();

Running the script will get us a serialized JSON text.
$ perl
[{"name":"Malaysia","capital":"Kuala Lumpur"}]

However, running this code in our test suite will hit the remote API server numerous times. While some API providers don't have a threshold of number of API calls, some do implement certain constraints to prevent abuse. There are two ways to overcome this limitation. First, we set a flag, typically environment variable in our test script to run the test on local development. If the return response is constant, we can actually cache the result locally as shown in next example, ``, using the special token, `__DATA__`. Notice that in the second script, we can even skip the request call and directly mock the `responseContent` subroutine.
use strictures 2;
use REST::Client;
use Test::Mock::Simple;

my $mock = Test::Mock::Simple->new(module => 'REST::Client');
$mock->add(responseContent => sub { return <DATA>; });

my $client = REST::Client->new;
# Optional.
# $client->GET(';capital');
print $client->responseContent();

[{"name":"Malaysia","capital":"Kuala Lumpur"}]

Continue with the code reading. The implementation of this module to mock existing method of a module is through overriding the method. This is done through Typeglob, which contains all the symbol table entry. The asterisk (*) character was chosen because it represents all data types. See the example code below in the module that implement this. The Typeglob was used to create an alias to the new overriding subroutine that we're going to mock.
    no strict;
    no warnings;
    *{$self->{module} . '::' . $name} = $sub;