blogs.perl.org

I have uploaded the first version of WWW::KrispyKreme::Hotlight. This is basically a Perl wrapper that interfaces with Krispy Kreme's location search page

Creating a new object like this:

# only supports geo right now
my $donuts = 
    WWW::KrispyKreme::Hotlight->new(where => [34.170833,-118.25]);

and calling the locations method like this:

my $locations = $donuts->locations;

will return a structure like this:

[   {   'storeHours2' => '',
        'locationId'  => '993',
        'hotLightOn'  => '0',
        'storeHours1' => '',
        'phone'       => '818-955-9015',
        'zipcode'     => '91504',
        'state'       => 'CA',
        'city'        => 'Burbank',
        'geoLocation' => '34.190000,-118.330000',
        'url'         => 'http://kkre.me/oXMuQQ',
        'title'       => 'Burbank',
        'address'     => '1521 North Victory Place'
    },
    {   'storeHours2' => '',
        'locationId'  => '985',
        'hotLightOn'  => '0',
        'storeHours1' => '',
        'phone'       => '323-291-4133',
        'zipcode'     => '90008',
        'state'       => 'CA',
        'city'        => 'Los Angeles',
        'geoLocation' => '34.010000,-118.340000',
        'url'         => 'http://kkre.me/pF3cuI',
        'title'       => 'Los Angeles',
        'address'     => '4034 Crenshaw Boulevard'
    },
...
]

Notice there is a boolean value for 'hotLightOn' which can be handy for finding fresh donuts!

CPAN: https://metacpan.org/module/WWW::KrispyKreme::Hotlight
Github: https://github.com/aggrolite/WWW-KrispyKreme-HotLight

A short note clarifying the results of an IRC incident.

On Feb 28, 2013 I gave a talk to Chicago.pm about Mojolicious. I called it an introduction, but I really wanted to show some of the features that sets Mojolicious apart. Because of this, the talk moves very fast. It hits routing and responses quickly, hits testing often, on all the way to well-tested non-blocking websocket examples.

I promised to get my slides up afterwards but life (i.e. my doctoral thesis) got in the way. Now with the release of Mojolicious 4.0 I thought I would take the opportunity to right a wrong and get the slides up; so here they are: http://mojolicious-introduction.herokuapp.com/!

The talk is itself a Mojolicious app, the source of which is available from on GitHub. Not only are all the code snippets shown in the talk included, not only do they all run, but they are actually what is rendered by the talk (DRY++), so what you see is what you get! Please leave any feedback and ask any questions. I may not see the responses here, so feel free to ping me elsewhere if needed.

I'm developing under Catalyst and am using the Catalyst test server that is running on my local machine and is reloading every time I'm saving changes to the source tree. This is a cool feature, but I have to wait in front of the browser until the application is loaded full and can answer http requests; if I hit F5 in the browser before it is up and running I get a connection refused error and have to hit it again.

Finally I got tired of that and wrote this little hack that shows a load indicator on my ubuntu desktop. The thing is very primitive. While Catalyst app is loading, it blinks yellow. If it has loaded ok, it shows green light for a couple of seconds and then disappears. If there was a failure (syntax failure in my case most of the time), it shows red light which doesn't go away until the problem is fixed.

I'm coding on the project with the other people, and not all of them are using the blinker,so the module is not turned on by default. In myapp.pl I have it like this:

if ( $ENV{BLINKER} ) { 
   require Catalyst::Blinker;
   Catalyst::Blinker->start;
}

before

Catalyst::ScriptRunner->run('MyApp', 'Server');

But if you _do_ want it on by default, you could do this instead:

use Catalyst::Blinker;
Catalyst::Blinker->start;

In both cases, the module recognizes $ENV{BLINKER} and parses the passed options (see below), f.ex.

$ export BLINKER=x=1900

( because by default if blinks on the top right corner of the desktop, and I use the line above to position in my first monitor, not the second).

So it twinkles :P

Hello, Everyone!

Since I think that live coding gives more flexibility and visual feedback than conventional REPL, here is approach to simple Perl live coding environment using Emacs, AnyEvent, PadWalker, Package::Stash and eval.

Live coding basically consists in performing evaluation of code when it comes from the text editor to a running script, but I also wanted persistent lexicals between eval's. One of ways is to predefine lexicals (or make simple context hash) and/or use $::somevar / $'somevar syntax to create/modify main package vars and/or define global lexicals with use vars qw($one @two %three). Live environment should have asynchronous capability, and AnyEvent was the first option that came to my mind.

Hence, I created perl script which represents running interpreter with optional (but default) PadWalker/Package::Stash processing in order to move my's declarations to global context. And some elisp stuff to communicate with running interpreter from emacs.

That's it - load perl-live.el in emacs, create scratch cperl-mode buffer, start interpreter (C-c C-l), open "*perl live*" buffer in other window to check output and have fun - evaluate line/region (C-c C-c) or something between braces (C-M-x). + *perl live* buffer behaves like REPL (in comint-mode)

Here is short screencast (frame dropped) of a live session with random stuff featuring PDL::Graphics::Simple, OpenGL w/ shaders, sub-processes, live http server modification (AnyEvent::HTTPD, Twiggy), interconnection with SuperCollider via OSC protocol using Net::LibLO and running Gtk2 / Prima / Tk / Wx / SDL - all at the same time, just to test whether it was possible )

.

p.s. i hope someone will implement similar front-end in other perl-friendly text editors in order to spread perl live coding

github

The famous libnet modules provide Perl programmers with a low level interface to POP3 and SMTP servers, among others.

This works fine in general but over the past years most mail servers stopped offering 'plain' SMTP and POP3 access, but use either SSL or TLS encryption. This has lead to a plethora of modules on CPAN to support SMTP via SSL or TLS and also for POP3 via SSL. Until recently this was not the case for POP3 using TLS security. But earlier this week Steffen Ullrich, the maintainer of IO::Socket::SSL, released a new version of Net::SSLGlue that also allows for connecting to POP3 over TLS. And as opposed to many of the other modules, it also allows to verify the SSL certificate on the remote server for extra security. Net::SSLGlue works for Net::SMTP, Net::POP3, Net::LDAP, and LWP.

Here is an example of how you can connect to a POP3 mail server over TLS:

"Plack - Perl Superglue for Web frameworks and Web Servers (PSGI toolkit)" as said in documentation. Dealing with perl applications deployment, which I do with chef - modern open source platform for configuration, I have written psgi cookbook to configure, install psgi applications. Here are some simple exmaples of usage which are self explanatory.

This snippet of code install Catalyst application as fast cgi standalone server:

psgi_application 'Catalyst FCGI application' do
    operator      'Dancer'
    application_user    'user'
    application_home    '/home/user/app/'
    script              '/home/user/app/scripts/foo.psgi'
    config              '/home/user/app/app.conf'
    action              'install'      
end

And this snippet of code installs Dancer application as Starman web server:

psgi_application 'Dancer Starman application' do
    operator                 'Dancer'
    server                     'Starman'
    port                        '5010'
    application_user    'user'
    application_home    '/home/user/app/'
    script              '/home/user/app/scripts/foo.psgi'
    action              'install'      
end

Checkout http://community.opscode.com/cookbooks/psgi for details.

Just reading Brent Laabs post on Porting a Module to Perl 6 and two things occurred to me. The first was that I should start getting into Perl 6 sooner rather than later and get the few modules I'm involved with changed over, ready for the big day.

The second and more important one is that, if I'm to assure myself that the module behaves in the same way as the Perl 5 module, the original tests need to pass. I would have invested much on those tests to verify the module works the way I think it should. To avoid finger trouble in re-writing those tests, I would sleep better if some kind soul could create the bit of magic that will parse [your favourite testing framework] and run it against my future Perl 6 module. Or, conversely, to write Perl 6 tests that run against Perl 5 modules and verify that the new suite is identical to the old suite, so I can then proceed with porting the module.

Maybe this is already possible in Rakudo. I don't even know how much I don't know.