Acme-CPANModulesBundle-Import-PerlDancerAdvent-2018
view release on metacpan or search on metacpan
Copyright (C) 1989 Free Software Foundation, Inc.
51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The license agreements of most software companies try to keep users
at the mercy of those companies. By contrast, our General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. The
General Public License applies to the Free Software Foundation's
software and to any other program whose authors commit to using it.
You can use it for your programs, too.
When we speak of free software, we are referring to freedom, not
price. Specifically, the General Public License is designed to make
sure that you have the freedom to give away or sell copies of free
software, that you receive source code or can get it if you want it,
that you can change the software or use pieces of it in new free
programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of a such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
General Public License and to the absence of any warranty; and give any
other recipients of the Program a copy of this General Public License
along with the Program. You may charge a fee for the physical act of
transferring a copy.
2. You may modify your copy or copies of the Program or any portion of
it, and copy and distribute such modifications under the terms of Paragraph
1 above, provided that you also do the following:
a) cause the modified files to carry prominent notices stating that
you changed the files and the date of any change; and
b) cause the whole of any work that you distribute or publish, that
in whole or in part contains the Program or any part thereof, either
with or without modifications, to be licensed at no charge to all
third parties under the terms of this General Public License (except
that you may choose to grant warranty protection to some or all
third parties, at your option).
c) If the modified program normally reads commands interactively when
run, you must cause it, when started running for such interactive use
in the simplest and most usual way, to print or display an
announcement including an appropriate copyright notice and a notice
that there is no warranty (or else, saying that you provide a
warranty) and that users may redistribute the program under these
conditions, and telling the user how to view a copy of this General
Public License.
d) You may charge a fee for the physical act of transferring a
copy, and you may at your option offer warranty protection in
exchange for a fee.
Mere aggregation of another independent work with the Program (or its
derivative) on a volume of a storage or distribution medium does not bring
the other work under the scope of these terms.
3. You may copy and distribute the Program (or a portion or derivative of
it, under Paragraph 2) in object code or executable form under the terms of
Paragraphs 1 and 2 above provided that you also do one of the following:
a) accompany it with the complete corresponding machine-readable
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
Appendix: How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to humanity, the best way to achieve this is to make it
free software which everyone can redistribute and change under these
terms.
To do so, attach the following notices to the program. It is safest to
attach them to the start of each source file to most effectively convey
the exclusion of warranty; and each file should have at least the
"copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) 19yy <name of author>
1. You may make and give away verbatim copies of the source form of the
Standard Version of this Package without restriction, provided that you
duplicate all of the original copyright notices and associated disclaimers.
2. You may apply bug fixes, portability fixes and other modifications derived
from the Public Domain or from the Copyright Holder. A Package modified in such
a way shall still be considered the Standard Version.
3. You may otherwise modify your copy of this Package in any way, provided that
you insert a prominent notice in each changed file stating how and when you
changed that file, and provided that you do at least ONE of the following:
a) place your modifications in the Public Domain or otherwise make them
Freely Available, such as by posting said modifications to Usenet or an
equivalent medium, or placing the modifications on a major archive site
such as ftp.uu.net, or by allowing the Copyright Holder to include your
modifications in the Standard Version of the Package.
b) use the modified Package only within your corporation or organization.
c) rename any non-standard executables so the names do not conflict with
devdata/http_advent.perldancer.org_2018_13 view on Meta::CPAN
<p>This year's calendar features twelve posts that cover a wide range of topics.
We feature several new authors, cover some new ground (for us!) with an
article on accessibility, and even have a crossover post showing how Dancer
can be used with other frameworks.</p>
<p>Without further ado, let's dance!</p>
<h2><a name="state_of_the_dancer"></a>State of the Dancer</h2>
<p>In 2017 and 2018, we saw fewer but more significant updates to Dancer and
Dancer2. With Dancer (1) being in maintenance mode, updates come only when
significant bugs are found, security vulnerabilities are found, or when a
change is proposed that greatly improve the lives of Dancer developers.
David Precious has been the light that guides Dancer(1) through the night,
and has been an excellent resource for both the Dancer and Dancer2 communities
on IRC and email.</p>
<p>Meanwhile, Dancer2 continues to grow and evolve, though at a less frantic rate
than earlier in its lifetime. Throughout the last two years, we've seen a
growing list of contributions from our community, through documentation
improvements, bug fixes, and new features.</p>
<p>At the end of 2017, the Dancer Core Team ran a survey of Dancer developers to
get community input on the Dancer project. We received an excellent response
to the survey, and it is being used to help guide the future direction of
devdata/http_advent.perldancer.org_2018_13 view on Meta::CPAN
<p>Several important performance improvements were made to Dancer2, the most
important of which being the migration from <code>MooX::Types</code> to <code>Type::Tiny</code>.
When <code>Type::Tiny::XS</code> is used, the boost is even more significant.</p>
<h2><a name="security_improvements"></a>Security Improvements</h2>
<p>Two important security features were added:</p>
<p>The session engine now requires a <code>validate_id()</code> method to be implemented in
the various session engines. This requirement shuts down an attack vector by
making session IDs conform to a known format.</p>
<p>SysPete implemented a <code>change_session_id</code> keyword to easily change the
current session ID. This is a common (and recommended) security practice,
especially when privilege level changes within an application.</p>
<h2><a name="author"></a>Author</h2>
<p>This article has been written by Jason Crome (CromeDome) for the Perl Dancer
Advent Calendar 2018.</p>
<h2><a name="copyright"></a>Copyright</h2>
<p>No copyright retained. Enjoy.</p>
<p>Jason A. Crome</p>
</div>
devdata/http_advent.perldancer.org_2018_19 view on Meta::CPAN
application. Easy!</p>
<h2><a name="some_gotchas"></a>Some Gotchas</h2>
<p>There are a couple of important nuances you should be aware of:</p>
<ul>
<li><a name="item_Environment_configuration_replaces_logging_configuration"></a><b>Environment configuration replaces logging configuration</b>
<p>If you put your logging configuration in <i>config.yml</i> rather than one of your environment-specific
configuration files (such as <i>environments/development.yml</i>), you stand a good chance of not using
the logging configuration you think you are using. The default configuration file for the development
environment, for example, logs only to the console. If you put your Log4perl configuration in <i>config.yml</i>
and don't change your development configuration file, your Log4perl configuration will be passed over
for the default console logger.</p>
<p>From my own experience, <b>always</b> configure your logger in your environment-specific configuration, unless
you use the same configuration across all environments (I don't endorse this practice).</p>
</li>
<li><a name="item_Core_level_messages_are_passed_as_log_level_trace__but_will_not_be_passed_unless_Dancer2_s_log_level_is_core_"></a><b>Core level messages are passed as log level trace, but will not be passed unless Dancer2's log level is core.</b>
<p>Since <code>core</code> doesn't have a good corresponding level in Log4perl, <code>core</code> level messages are sent
over to Log4perl at the <code>trace</code> log level. This <b>only</b> happens when you set Dancer2's log level in your
<i>config.yml</i> file to <code>core</code> however. So your preferred log level setting is respected, even if <code>core</code> level
messages have to be reported at a different level.</p>
</li>
devdata/http_advent.perldancer.org_2018_23 view on Meta::CPAN
<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> 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> %m in %f l. %l"</pre>
<p>Usually you would run a single-worker server during development, so there is no need for request IDs.
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> %m
# 20/Dec/2018 16:41:07 MyApp.pm:22> 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>
<p>This will find customer numbers according to the pattern and make them bold and red. You can supply
devdata/http_advent.perldancer.org_2018_24 view on Meta::CPAN
things we have in store for 2019:</p>
<ul>
<li><a name="item_New_Documentation"></a><b>New Documentation</b>
<p>You asked for it, and I made reference to it on day 1, all new documentation is coming in
2019. While many of you love the docs, a lot of you don't, and thanks to your comments in last
year's survey, we think we have a good understanding of why.</p>
<p>The new documentation branch is well underway, and addresses the shortcomings of the existing
documentation by explaining important concepts in a clear and simple way. You'll have a better
understanding of how and why Dancer2 does the things it does.</p>
<p>New users will get some grounding in web development techniques, too. There's a lot of great
changes for everyone!</p>
</li>
<li><a name="item_New_Website"></a><b>New Website</b>
<p>There's a lot of great information on the Dancer website, but it's looking tired. There's a
lot of new information to be added, and with a fresh coat of paint, Dancer's website will be as
great as the software powering it.</p>
</li>
<li><a name="item_More_configuration_options"></a><b>More configuration options</b>
<p>Configuration in Dancer2 leaves a lot to be desired (and I'll admit that I am a big part of
the reason for why that is). Look for an overhaul of the configuration system in 2019, which
starts with a barebones configuration system and allows for pluggable configuration engines
(much like loggers and sessions in Dancer2). Since we are dedicated to not breaking working
code, all of the existing configuration logic would be packaged as a plugin and enabled
out of the box.</p>
</li>
<li><a name="item_Inline_parameter_type_checking"></a><b>Inline parameter type checking</b>
<p>Very similar in many ways to Sawyer's <a href="https://metacpan.org/pod/Dancer2::Plugin::ParamTypes">Dancer2::Plugin::ParamTypes</a>
plugin, but provided as core functionality. SysPete is actively developing a way to provide
(optional) type checking of parameters within the core of Dancer2.</p>
<p>In case you haven't read <a href="http://advent.perldancer.org/2018/22">Sawyer's article</a>
about type checking parameters passed to your Dancer applications, I highly recommend
it. It will change the way you do data validation.</p>
</li>
<li><a name="item_Continued_support_for_Dancer__1_"></a><b>Continued support for Dancer (1)</b>
<p>While most all of our effort is spent on Dancer2 these days, there are no plans to sunset
Dancer (1) as of now. Many of the core developers are still actively maintaining applications
written in Dancer, as is much of our community.</p>
<p>It is still our hope, however, that with an easy migration path from Dancer to Dancer2 that more
of you will make the switch in 2019.</p>
</li>
</ul>
<h2><a name="happy_holidays_"></a>Happy Holidays!</h2>
( run in 1.299 second using v1.01-cache-2.11-cpan-5dc5da66d9d )