Now to circle back again. You may remember many many posts ago I wanted to make it a requirement for my LSD writers to have an SQL sub. I later revised the name to be a _retrieve sub that would be used to format the query up before it goes off to the DB/

Well in the end I think I am just going to leave it up to the LSD writer to write those subs as they see fit.

In the long run I think that is the only way to go as there is no way I can abstract out from my set and into a set of functions that covers every situation. So I guess my Christmas present for my LSD writes it the joy of just using the attributes that I supply from the DA.

Hey everyone,

Following is the p5p (Perl 5 Porters) mailing list summary for the past few days. Enjoy!

This summary was accidentally deleted and now restored. :)

GitPrep 2.0 is released at 2016-5-7. GitPrep is portable clone of GitHub. GitPrep work on CGI and own server. GitPrep 2.0 is major version up. It supports Pull request.

GitPrep

Added features is that:

• Support mail address. you can identify user by mail address.
• Adding to user id, you can set user name.
• you can set encoding, and diff option(which ignore space) at each project. If you write the setting in config file, you set these settings at project setting page.
• Header for reverse proxy is change to X-Forwarded-Proto from X-Forwarded-HTTPS
• Needed temporary file is created in gitprep directory. not more depend "/tmp"

GitPrep image and example

The following is GitPrep example URL. This is run as CGI at sakura rental server. If you access the following URL, You can use GitPrep. It support SSL.

GitPrep example

Incompatible change

Hi!

It seems Sparrow project is getting stabilized with version 0.1.*, I don't think I am going to change API radically in the future ... The same for Outthentic which accordingly hit version 0.1.* as well.

So to sum things up:

So the time has come to pick which of the thee patterns I am going to choose to carry on. So here is how I evaluated each one giving advantages first.

Pure Moose;
Accomplished all system requirements, loaded and ran fast, required the least number of external modules, code easy to implement by LSD writers.

Requires the use of 'Klugeish' code son the DA side. The call '$class->new' can be confusing to some as this appears to be some sort of majik var. Options available on the interface are limited.

MooseX::ShortCut::BuildInstance;
Accomplished all system requirements, interface has many options which may prove useful, good name-space management, code easy to implement by LDS writers, clear interface on DA side of coding.

Slowest to load, has a moderate number of dependencies,

MooseX::Scaffold
Accomplished all system requirements, interface has many options which may prove useful

Second slowest to load, has a few dependencies, the code requires the most from the LSD writer and the interface for the DA writer is the largest.

The author tests in my module publication pipeline are only one part of the task. The other tasks are actually running the checks, making sure that my public Github repositories are updated with each release and actually pushing the distribution file out onto CPAN. Of course, I have these steps automated.

Years ago I wondered intensely about why some acronyms jarred, and not just government-issue ones either. Let me explain my conclusions.

I'm posting this now because of the push to rename the just-finished QA Hackathon, which personally I feel was marvellous value-for-money.

Over on Perlmonks I wrote that you should probably use this:

say join '', @array[2,4];

Instead of this:

local $" = '';
say "@array[2,4]";

And my reasoning being:

Why is that better? Because nobody knows what $" is, but everyone knows what join() is. Always write your software to be as readable as possible :)

I received a couple of upset replies along the lines of "Perl devs should be allowed to write Perl!" While I generally agree with that sentiment -- I had no problem with the array slice, for example -- I think the replies came, in part, because I had answered too quickly. I clarified what I meant, but I thought I should explain it here, too, because too many people reach for those punctuation variables.

So now that that I have three prototypes out there for DA

1. Pure Moose
2. MooseX::Scaffold and
3. MooseX::ShortCut::BuildInstance

The question becomes which one to to choose. They all do what I want them to enforce my API , keep the LSD code from beading into the DA code and all allow me now enter just a connection object and the correct LSD will be loaded.

One thing to do is run some benchmark test to see how fast the various scripts load and then run. I might not matter at this early stage bu I could see that the LSDs could become rather extensive as my original one was something like 2000+ lines of code and that could take some time to load.

I know it is rather old school of me to look into this as given the speed of modern system instaniating my object would likely be one of the quicker part of the code and the actual query would be the long part of this code, but every little bit helps.

Every now and then, I enjoy solving logic puzzles (or attempting to). Recently I came across this one:

+----+----+----+
|    |  3 | 17 |
+----+----+----+
|  5 |    |    |
+----+----+----+
| 13 |    |  7 |
+----+----+----+

Strawberry Perl 5.22.2.1 is available at http://strawberryperl.com

More details in Release Notes:
http://strawberryperl.com/release-notes/5.22.2.1-64bit.html
http://strawberryperl.com/release-notes/5.22.2.1-32bit.html

I would like to thank our sponsor Enlightened Perl Organisation for resources provided to our project.

Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA

I can't actually say when they moved, but Petr Pisar has kindly informed me it is so, and he's fastidious about such things.

And, yes, here in Australia we really do spell licence as, er ... well, licence.

Now I do have a working version of the MooseXs Scaffold and Shortcut and even built out the Shortcut version to not hard-code the LSD classes I might have to load. Now what I do not have a pure Moose version so I think I will stub that out now using what I have learned form the other Modules.

Now it really did not take much time or effort to make this a pure Moose mod. All I had to to was make some adjustments BUILD like this

– grep { -d $_ } map { File::Spec->catdir($_, 'DA_SC','LSD' ) } @INC;
++ grep { -d $_ } map { File::Spec->catdir($_, 'DA_PM','LSD' ) } @INC;

and the same sort of thing in my '_loadLSDClassesFromDir' sub like this

Last Friday Test-Simple 1.302014_009 was released. That plan was to bump that distributions version number and release it as stable this Friday May 6'th.

Since that release a number of minor bugs have been fixed. Most of these are typo fixes and documentation changes. There were also some mistakes in our x-breaks meta-data that needed to be corrected. Finally there was one bug fixed that was not as minor, a 64-byte shared memory leak when using threads.

I have decided that these fixes, in particular the last one, are important enough to put out a new dev release, and bump out the stable release date. 1.302014_010 will hit cpan today. Assuming no other substantial bugs are found the new release date will be Tuesday May 10'th. Obviously being correct is more important than releasing by a specific date, so if significant items are found the release could be delayed again.

If you find any bugs or issues please report them right away at https://github.com/Test-More/test-more/issues.

Since my recent participation at the QA Hackathon I have become aware that rather more people than I expected do not know the specifics of this situation. Fewer than I expected have heard of it at all, even, although there appears to be some general awareness at the “something happened with that” level at least.

However, the situation is being used to characterise Marc Lehmann whenever his name comes up (and it comes up rather more often than I would expect or consider necessary).

To give a clear picture of the facts and to avoid repeating that exercise every time I have a related conversation, here is an outline of where we are and how we got here.

(Thanks to Andreas König, Graham Knop, and Peter Rabbitson for proofreading drafts of this article and verifying the stated facts.)

Ahoy, matey! I heard thar be traitors in our ranks! We need t' search t' ship 'n find every last one o' them, put them through exquisite torture, 'n then make them swim t' plank. Now t' ye, I gift a task! Learn everythin' ye can 'bout these traitors 'n all o' t' "traits" they use. Ye succeed, a full barrel o' spiced rum gunna be me generous gift t' ye!

PART I: Built-In Traits

Traits! In Perl 6, they're subs executed at compile time that make your code tight and sexy. There's a whole bunch of them built into Perl 6 and today we'll explore some of them.

is ...

sub foo ($bar is copy) is export { ... }
has $.foo is rw is required;
class Foo is Bar { ... }

There are several built-in traits that you apply with the is keyword. Let's take a look at some of the oft-used:

is export

So from my last post I had to figure out a way to enforce these four rules

1. All LSD files will be in the DA::LSD name-space or folder if you like
2. Each DSL has to express which type of driver it expects
3. Only DSL 'pm' files will be loaded
4. The loaded DSLs should be cached as loading or at least requiring them may take some time.

The first question is where to do this in the code. Fortunately Moose has a BUILD sub which is the prefect place for this. So we will start with this;

sub BUILD {
    my $self = shift;
    map { $self->_loadLSDClassesFromDir($_) }
      grep { -d $_ } map { File::Spec->catdir($_, 'DA_SC','LSD' ) } @INC;
}

I write comment at the following entries.

How about separating dynamic world and static world?

Current subroutine signatures implementation contains two features which purposes are different

As you're probably very aware by now, the Perl QA Hackathon was last weekend, and it was a great success. Just under 40 people assembled in Rugby in the UK, to work on the Perl and CPAN infrastructure that everyone using Perl relies on. Many bugs were fixed, problems solved, ideas germinated, and cans kicked down the road. Those same people working alone for 4 days would not have achieved anywhere near as much, and that's why we do this, every year.

This year I've had the chance to attend the Perl QA Hackathon as "the intern". Needless to say, it was an honor and a great pleasure to take part in the event and go through a very stimulating 4 days coding and discussing with people I have a huge respect for and whose work has been a reference for me since I started my journey in the perl world.

I have to admit I was going to the event feeling quite a bit of pressure: I wanted to be able to be helpful and contribute work but, at the same time, to not be too disruptive.
Regarding that, I was honestly very surprised with how welcomed the rest of attendees made me feel since the very beginning. Honestly, I do believe this is quite unusual in tech communities and, therefore, I think it deserves to be valued.
Without any kind of doubt this was key in making me feel comfortable and being much more productive during the hackathon (thanks!).