Comparing the three possible ways to define constants (Const::Fast, Readonly, constant) I found Const::Fast to be the best. It is very light and operates directly on Perl's internal SvREADONLY. It adds almost none processing overhead. Readonly is much heavier (its implementation is quite complex) and it has a performance overhead (as its documentation clearly states). The third way, Perl's default standard constant, is annoying when concatenating strings since it doesn't interpolate.
I just converted a project consisting of 75 Perl source code files to use Const::Fast exclusively. It was an easier task than I expected. First I forgot to use "=>" in assigning the value and used "=" instead. This resulted "Type of arg 1 to Const::Fast::const must be one of [$@%]..." errors. After these were fixed I needed to change the code in approx. 15 places to use "exists" to test key presence (see documentation CAVEATS). But these steps were all. I then did some testing to verify that Const::Fast::const actually protects the data and yes, the data is protected: the program dies with "Modification of a read-only value attempted" or "Attempt to access disallowed key '*****' in a restricted hash".
Very handy module that instantly solved my problem of detecting the correct language for my website. But notice that as the documentation states if you don't provide the default language you may get an empty string returned. I just wrote "defaultLanguage" as "defaultLangauge" and got empty strings wondering what was going on ... but it was my fault!
Install the module, add a call to it into your code and you're done. Modules like this don't get much attention but they make your life with Perl a lot easier. HTTP::Date does its task and does it well while staying out of your way.
Yet another excellent CPAN module that has become a standard tool for me. And remember this statement comes from a guy that is against micro-optimization and thinks that adding print statements is a debugger. In general by using Devel::NYTProf you get a clear view of where your application spends all its time. In practice I noticed that my web application spent more time on custom string encoder than with database queries. With a few changes the time was dropped from 428Âµs/call to 11Âµs/call and I can notice that in the application response times. Thanks to Devel::NYTProf I now understand what is slow in Perl (calling substr) and what is fast (a hash lookup). But as with any profiler if you are not into all the technical stuff this module is not for you.
This is the most comprehensive Perl caching module available. With this module you get a very rich interface and you are always prepared for backend changes. I just dumped my custom caching module running only on Memcached in favor of CHI. I had some issues with Memcached on Windows but now with CHI I can use file backend on Windows and Memcached backend on Linux. And in the future I might like to switch to DBI backend on both platforms. With CHI these backend changes are trivial and can be completed within a minute!
One of the core modules that I couldn't live without. Excellent feature set for relational database access. All viable relational databases on earth are supported. I've been using DBI with Oracle, Postgres and SQLite with no major issues. The user community is so huge that so far I haven't come to a question that a Google search couldn't answer.
Years have passed but Mason still stands strong! What comes to sane component-based web application frameworks with Perl embeddability there seems to be no real alternatives to Mason. Mason is very mature and the documentation is excellent (including the online book and Mason HQ). I find Mason-based applications to be more logical, easier to develop and simpler to debug than MVC alternatives. I think it is because in Mason your don't have that MVC stash variable running amok but nice components with clear call interfaces. And the best part is just to come: it's excellent to hear that Mason 2.0 appears to be under development! The early signs look very promising like using Moose under-the-hood.
It was great to discover this module. I needed to implement a ultra-fast search engine on a limited amount of data and decided to try bit vectors. Luckily there was no need to implement the algorithms by myself due to this high-quality module. The speed: simple operations complete in a few nanoseconds and complex operations is a few milliseconds on a vintage PC!
Catalyst is the current industry standard what comes to Perl MVC frameworks. Just check the number of plugins available on CPAN: just overwhelming! You really can't go wrong with Catalyst if Perl and MVC is what you need.
Mojolicious is the current state-of-the-art solution what comes to Perl and MVC frameworks. It is modern, lightweight and clever. It has the best dispatcher I've seen. The integrated templating engine is both feature-rich and runs fast. The reload option really speeds up the development. Error messages and log messages are easy to understand. Mojolicious is the major contender in the Perl MVC scene.
This is THE FASTEST template engine around. My personal test results match with Sam Graham's Perl Template Roundup. I give Xslate a big thumbs up not only because of the speed but also because of the features like object oriented syntax, Perl function API and Template Toolkit migration path.
MicroMason is an impressive piece of work. It provides Mason-like syntax but in a lighter and faster package. The performance is excellent as seen in Sam Graham's Perl Template Roundup. If you dig Mason syntax but need only the templating engine (and not the heavy-weight application framework provided by Mason) then MicroMason is the module for you.