view release on metacpan or  search on metacpan

devdata/https_mojolicious.io_blog_2017_12_13_day-13-more-about-roles  view on Meta::CPAN

my $anchors = $dom->find_custom;
</code></pre>

<p>And finally that looks quite nice.
It should be noted that this shortcut usage is different from some other plugin systems on CPAN, some of which use <code>+</code> to indicate a literal (ie non-shortened) class name.
We feel that you should be explicit about requesting a non-literal class name and so we made this choice.</p>

<p>Now sometimes you don&#39;t instantiate the class, sometimes you have an instance given to you.
For example say the Mojo::DOM document came from a <a href="http://mojolicious.org/perldoc/Mojo/UserAgent">Mojo::UserAgent</a> request.
In this case you can still use <code>with_roles</code>.
What happens in this case is that a little magic happens in the background to add the functionality to the instance.</p>

<pre><code>my $dom = $ua
  -&gt;get(&#39;http://mojolicious.org&#39;)
  -&gt;res
  -&gt;dom
  -&gt;with_roles(&#39;+FindCustom&#39;);
my $anchors = $dom-&gt;find_custom;
</code></pre>

<p>Finally, when you are checking if a class consumes a role, you don&#39;t check with <code>-&gt;isa</code> as if it were inheritance.

devdata/https_mojolicious.io_blog_2017_12_22_day-22-how-to-build-a-public-rest-api  view on Meta::CPAN

<p>This post look into how to write an API specification and how to use it
together with
<a href="https://metacpan.org/pod/Mojolicious::Plugin::OpenAPI">Mojolicious::Plugin::OpenAPI</a>
and <a href="https://metacpan.org/pod/OpenAPI::Client">OpenAPI::Client</a>.</p>

              </section>
              <section id="section-2">
                  <h2>Why would you use OpenAPI</h2>

<p>This question comes up quite often after telling people about OpenAPI:
&quot;but...why?&quot; The people asking this often come from the same background as
myself, where you both write the producer (backend web server) and consumer
(JavaScript, ...) of the data. When you&#39;re in complete control of both sides
you don&#39;t really need to write any formal specification or document your API,
since you already <em>know</em> how it works. This can be very true - at least if you
make sure you have tests of all your endpoints.</p>

<p>Personally I&#39;m a <a href="http://www.linkognito.com/images/05-08-08/metal.gif">huge fan</a>
of documenting as well as testing. I often say that if you can&#39;t document
(describe) the API/method/whatever, something is wrong and you should reconsider
what you&#39;re coding. Documenting an API on the other hand is awful in my opinion,