Test::DeepMock is a abstract mock factory which injects mocks into @INC so whenever your app requires a package - mock will be loaded. Extremely useful for testing old legacy code.

This is a static file server (most codes are stolen from Plack::App::File) with additional feature gzip_static, known for nginx and Apache.

I want to create a client for the CDNetworks's Cache Flush Open API v2.4.0 service. These are the namespaces that I considered: * WebService::CDNetworks::Purge (I think the most appropriate) * WWW::CDNetworks::Purge * NET::CDNetworks::Purge

Net::Object::Peer is a Moo Role which implements a publish/subscribe peer-to-peer messaging system, based upon Beam::Emitter. Objects in the network may broadcast events to all subscribers or may send events to a particular subscriber.

Subscriptions and unsubscriptions are tracked and messages will be sent to affected objects upon request.

While Net::Object::Peer is designed around the concept of nodes being objects with methods as event handlers, it retains Beam::Emitter's ability to register code references as well.

Net::Object::Peer::Cookbook provides some recipes.

I'm not terribly enamored of the module name; suggestions for alternatives would be welcome!

I'm working on a module that will allow a developer to write "Classes" in Perl. Then, the developer will be able to call methods in those classes from either the command line, cgi, web sockets, stand-alone web servicer, or from native Perl. The classes will be self documenting and will benefit from parameter type-checking. My module will allow the developer to specify both the input and output data format, such as text, csv, html, json, xml, Perl hash, etc. Finally, configuration/authentication information can be segregated from the main code and perhaps even stored outside of the normal web-space.

So, you would be able to create an Object Class Module and be able to call those methods from the command line during testing. Then you could deploy the same code via cgi for your web applications. At scale, this same code would be available via a stand-alone server.

During testing, you could supply the data via xml and get the results in json, if you wanted.

I'd like to know if the package name Geo::Converter::LV03 is possible for a package that exposes to methods to convert coordinats from WGS84 to the Swiss LV03 coordinate system and vice versa.

Perl wrapper for Watson's Alchemy Data News API: https://www.ibm.com/watson/developercloud/alchemy-data-news.html

The Alchemy Data News API is a very powerful REST API capable of searching news and blog posts for keywords across specified time frames. The API also enriches the articles with various natural language processing techniques that allow the user to perform highly targeted searches.

This module interprets Perl syntax into the REST parameters the API expects.

Sub::QuoteX::Utils provides a simplified interface to the process of combining Sub::Quote compatible code references with new code.

Sub::Quote provides a number of routines to make code more performant by inlining separate chunks of code into a single compiled subroutine.

When a chunk of code is compiled into a subroutine by Sub::Quote::quote_sub(), Sub::Quote keeps track of the code and any captured variables used to construct that subroutine, so that new code can be added to the original code and the results compiled into a new subroutine.

Sub::QuoteX::Utils makes that latter process a little easier.

MojoX::Log::Any makes it easy to use a Log::Any::Adapter from within Mojolicious without getting in the way of the user.

When imported from within a Mojolicious application (of from within a package into which Mojolicious' app function has been exported), it sets that application's log attribute to a Log::Any::Proxy connected to whatever adapter is currently available.

When imported, the logger defaults to using Log::Any::Adapter::MojoLog, which seems to be the currently maintained adapter for Mojo::Log. Any parameters passed to the module's import function are passed as is to the get_logger function from Log::Any, to allow for user customisation and to maintain a coherent interface with that package.

Motivation

There are numerous packages in the MojoX::Log namespace providing an interface with the various different logging mechanisms on CPAN; except Log::Any.

There is also a Log::Any adapter for Mojo::Log, which makes it possible to use that logger from any application using Log::Any; but not Mojolicious apps.

This package attempts to fill that void by offering Mojolicious applications an easy way to plug into the current Log::Any::Adapter (whatever it may be).

Mojo::IOLoop::Signal is a Mojo::IOLoop based, non-blocking signal handler.

Questions:

• Why does not Mojo::IOLoop officially support signals?
• Do you think this module useful?
• Any feedback is welcome.

Thanks.