Acme-CPANModulesBundle-Import-PerlDancerAdvent-2018

 view release on metacpan or  search on metacpan

devdata/http_advent.perldancer.org_2018_16  view on Meta::CPAN

    </ul>
</li>
</ul>
</div>


<div id="content">
<div class="pod-document"><h1><a name="using_minion_in_dancer_apps"></a>Using Minion in Dancer Apps</h1>

<p>At <code>$work</code>, we have built an API with Dancer that generates PDF documents and XML files. This API is a critical component of an insurance enrollment system: PDFs are generated to deliver to the client in a web browser 
immediately, and the XML is delivered to the carrier as soon as it becomes available. Since the XML often takes a significant amount of time to generate, the job is generated in the background so as not to tie up the 
application server for an extended amount of time. When this was done, a homegrown process management system was developed, and works by <code>fork()</code>ing a process, tracking its pid, and hoping we can later successfully
reap the completed process.</p>
<p>There have been several problems with this approach:</p>
<ul>
<li><a name="item_it_s_fragile"></a><b>it's fragile</b>
</li>
<li><a name="item_it_doesn_t_scale"></a><b>it doesn't scale</b>
</li>
<li><a name="item_it_s_too_easy_to_screw_something_up_as_a_developer"></a><b>it's too easy to screw something up as a developer</b>
</li>

devdata/http_advent.perldancer.org_2018_21  view on Meta::CPAN

<div id="content">
<div class="pod-document"><h1><a name="spam_and_bot_prevention_without_the_use_of_captchas"></a>Spam and bot prevention without the use of CAPTCHAs</h1>

<h2><a name="the_problem"></a>The problem</h2>

<p>I was writing a contact form for my LLC, and having been the victim of an automated form-filler in the
past, I wanted to prevent getting spammed by my own contact form. My first instinct told me to add a CAPTCHA
to the form as a means to ensure there's a human at the keyboard. But as it turns out, this isn't a great 
solution for a variety of reasons.</p>
<h2><a name="a_little_background"></a>A little background</h2>

<p>I worked with my friend Job a few contracts back, and he is passionate about developing accessible software and
educating other developers about accessibility issues. Job really opened my eyes to a lot of bad development 
practices, and the problems they caused for users with accessibility needs. So when he heard I wanted to
put a CAPTCHA on my form, he nearly had a stroke. When the initial shock wore off, we talked about how I could
accomplish my goal, but do it in an accessible way.</p>
<p>CAPTCHAs come in a number of shapes and sizes. At the time I wrote this, reCAPTCHA was the latest hotness. 
It featured text that was really hard to read, and on occasion, featured audio for those who couldn't see or 
read the text. They were also unfortunately stupidly easy to crack, and thanks to Mechanical Turk and other
tricks, they quickly became a useless piece of nuisance for your average web user.</p>

devdata/http_advent.perldancer.org_2018_23  view on Meta::CPAN

<p>The <code>colored_levels</code> are the log levels themselves.</p>
<pre class="prettyprint">[main:28764] debug @2018-12-19 20:31:06&gt; Hello World in test.pl l. 6
             ^^^^^</pre>

<p>And the <code>colored_messages</code> refer to the actual message.</p>
<pre class="prettyprint">[main:28764] debug @2018-12-19 20:31:06&gt; Hello World in test.pl l. 6
                                         ^^^^^^^^^^^</pre>

<p>The colors are the same kind of color strings used by <a href="https://metacpan.org/module/Term::ANSIColor">Term::ANSIColor</a>. The first
color refers to the foreground, and the second one to the background. You can add an optional <code>bold</code>.</p>
<pre class="prettyprint">[bold] [foreground] [on_background]</pre>

<h2><a name="changing_the_log_message"></a>Changing the log message</h2>

<p>If you don't like the default log format, you can change it with the <code>log_format</code> setting, which is
documented in detail in <a href="https://metacpan.org/module/Dancer2::Core::Role::Logger">Dancer2::Core::Role::Logger</a>. You can just stick it in with the other configuration.</p>
<pre class="prettyprint"># config.yml (this is the default)
engines:
  logger:
    Console::Colored:
      log_format: "[%a:%P] %L @%T&gt; %m in %f l. %l"</pre>

devdata/http_advent.perldancer.org_2018_23  view on Meta::CPAN

And since the message is now colored, we can also drop the log level. How about a simple format like
the following:</p>
<pre class="prettyprint">%t %f:%l&gt; %m
# 20/Dec/2018 16:41:07 MyApp.pm:22&gt; Hello World</pre>

<h2><a name="i_know_regular_expressions_"></a>I know regular expressions!</h2>

<p>Sometimes just reading the log is not enough. You're looking for a specific piece of information. There
are three pages of log for a single request, and debugging is hard work. Grepping is an option,
but you need to look for a complex pattern. Maybe a product SKU, a date or some other piece of information.</p>
<p>With Dancer2::Logger::Console::Colored you can actually make it come out with a background color so you
can spot it easily, without having to change your code (or your added debugging log statements). Instead,
you can put a regular expression into your configuration file.</p>
<pre class="prettyprint"># config.yml
engines:
  logger:
    Console::Colored:
      colored_regex:
       - re: "customer number \d+"
         color: "bold red"</pre>