This is the second instance in recent time where I thought it was a quick fix but ended up taking way more time than it should. The first was an iOS app submission which was something Apple changed recently. This is a perl example so posting it here.
Mandrill is shutting down . I was using their service for my domains table tennis match and Brainturk brain games online . I looked at the alternatives and settled with sparkpost . This is the sparkpost example for using perl . It seems simple enough so I asked my employee who is learning perl to try it out . When we ran the example we started getting an error . This example uses Net::SMTP and running it in debug mode gave us this
RCPT TO: <firstname.lastname@example.org>
550 5.7.1 relaying denied
As some of you might have heard, Ricardo Signes had stepped down from the role of Perl Pumpking. He passed on that role to me.
I have written the following message to Perl 5 Porters, and I think it seems apt to provide it at large to the community here:
("group" in this context is the Perl 5 core development group: p5p.)
If you ever wanted to test your CPAN modules on Windows systems without having an own Windows system setup, then you should take a look at AppVeyor. Basically it's something like travis-ci, but just running on Windows. Configuration happens in a YAML file named appveyor.yml.
A sample appveyor.yml file for testing CPAN distributions may look like this:
- if not exist "C:\strawberry" cinst strawberryperl
- set PATH=C:\strawberry\perl\bin;C:\strawberry\perl\site\bin;C:\strawberry\c\bin;%PATH%
- cd C:\projects\%APPVEYOR_PROJECT_NAME%
- cpanm --installdeps .
- perl Makefile.PL
- dmake test
The install entry is installing StrawberryPerl using chocolatey, a package manager for Windows, and CPAN dependencies with cpanm. The build_script entry is actually building and testing the distribution. These two entries are actually necessary for a minimal appveyor.yml file. The cache entry is useful to cache the downloaded StrawberryPerl, and, maybe more importantly, especially for large dependency trees, any CPAN module which was installed in the "install" step. The branches entry is just a private convention of mine (branches named XXX-travis-ci should be tested only on travis-ci and XXX-appveyor only on AppVeyor).
Here are more sample appveyor.yml files:
Back in the fall of 2013 I began working on a project called C::Blocks. After
some very long detours the project is finally coming to fruition. I recently
took it for a spin on a benchmark from the benchmarksgame. The results? Let's
just say I was very surprised.
In some code I’m working on, I use a module which exposes a whole bunch of package variables as part of its public interface. It does not export them, however. I could refer to them directly by prefixing them all with
Some::Module::, but that would be ugly and verbose. It’s also unsafe – the
vars stricture will not help you catch typos if you use fully qualified names.
The obvious solution would be to emulate what exporting does:
This year was my first Perl Quality Assurance Hackathon, and even then I could only make 2 of the 4 days. I now wish I'd been to everyone ever, and for the full time!
I've been working on the MetaCPAN project for over 4 years, taking on the puppet master/sysadmin/development VM builder type role, even though that's not really my day job. So after all this time to actually meet Olaf Alders and the recently joined Mickey was a great pleasure:
Originally written for providing installable themes for my photo
publishing app, App-imagestream, I wrote two modules that make it very easy to provide a basic theme for a web application in an archive. This still allows for quick customization by overlaying the contents of the
archive with the contents of another archive or a directory in the file system.
As many people know by now, Ricardo Signes recently announced that he
will be standing down as pumpking once Perl 5.24.0 is released, after
four and a half years in the role — not to mention an unprecedented five
stable 5.x.0 releases of Perl!
Since the Perl QA Hackathon is the first Perl event Rik has attended
since his announcement, we thought it would be fitting to offer Rik a token
of our appreciation for the remarkable and tireless work he’s put in during
his service. So we closed up the second day of the hackathon with a short
presentation and a small expression of our gratitude (and hopefully one that
Rik didn’t find too embarrassing!)
In particular, Rik has now joined the very select group of people who’ve
received a Silver Camel.