May round schedule will be similar to the March round, with several changes as below.
- Longer period to solicit community feedback
- Longer voting period
- Shorter CFP period
In the long run, CFP period should be shortened further as every round will look the same and preparation can be done beforehand. Or even easier, we may always keep the CFP open and evaluate the applications every two months.
Here is the May schedule:
- May 1: CFP opens
- May 10: CFP closes
- May 11: Solicit public feedback
- May 22: Voting
- May 31: Announcement of the results
CFP will be posted at news.perlfoundation.org.
The following data is from a 64bit perl-5.19.10 (i.e. 32 bit jenkins - corrected from 64 bit siphash - which randomly shuffles the 2 first entries of collisions), running the core test suite with -DH.
number of hash keys:
Well my last post trying to work with MooseX::ClassCompositor was a bit of a bust as it is not what I needed. So onto the next one one my list 'MooseX::ShortCut::BuildInstance' so lets have a look and see what this one can do for me.
Well at first glance it seems a hybrid of the last two, it does follows the same basic pattern, give a base class add some roles and then get a instance. With this mod I don't have to build a factory class like I do for MoosX::Facotry but I can supply a base class which I could not do for MooseX::ClassCompositor so things look promising.
This one also has the best documentation but it still is very sparse but informative. The tests are a little more elaborate but still very basic and a funny thing he uses them in the synopsis in the POD haven't seen that often.
So lets give it a try
So what’s new?
- Follow the meta-2 phase-requirements naming.
- The ablity to recast phase-requirements.
Plus theres more
- App::Midgen v0.30 which was a refactor to support Perl 5.8.x
A Couple of other blogs that now make sense to share with you
for the rest of the blog go here
Any comments leave them here.
The following is posted on behalf of Roman Filippov and Al Newkirk, kindly share your thoughts on the mentioned points.
I would like to propose the following items for discussion, in no particular order. This is just a brain dump of the ideas I have been thinking for a while now.
In my last post I had a look at how MooseX::Abstract::Factory worked and what it could do for me. Today I will continue down my little list and have a look at
'MooseX::ClassCompositor' and see if this one fits into what I am trying to do.
Well at first glance it seems this could really work for me. Start with an empty class and add in all the roles. So lets have a closer look. Like the last module the documentation is slim and the test suit contains little more than the synopsis so no pointers there.
Well this might be good for game time but I am not sure if it will work with my present class structure and trick. Seem I have to have everything a role. Well lets give it the old collage try
My current contract is lovely. I'm having a lot of fun and the environment is awesome. However, it's a short contract. I took it, in part, because it was a problem space I wanted to do more work in. Because it's a short contract I'm already working on negotiating my next contract (a perpetual hobby for freelancers), but I thought I'd experiment with a different approach: asking you to reach out to me. If you think I can help your company and you're not in a position to hire me directly, go to those who are and talk to them. If you want to hire me or one of the talented developers who works with me, drop me a line (I can't guarantee that I'm available, but you never know). If this approach works, I can do more work on open source or Veure instead of spending all of my "between" time negotiating contracts.
That being said, I don't always get contracts I negotiate for and sometimes I turn them down. However, if you're an individual considering freelancing, I thought it worth discussing some of the obstacles I've faced.