blogs.perl.org

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.

I recently updated a client called WebService::Geocodio for the Geocod.io geocoding service. Traditionally, geocoding means turning a mailing address into latitude/longitude coordinates (or the reverse operation, turning latitude/longitude into a mailing address.)

In a recent update of the upstream service they included the ability to fetch additional data fields including timezone, congressional district, school district and so forth. Is there a good CPAN module (or a recommendation) to take a Perl data structure like a hash and turn it into a Moo(::Lax) object "automagically?" I had a look but I didn't find anything especially suitable.

These data structures are purely informational in nature and just have getters for their attribute names. This would be less difficult to accomplish using Moose (obviously) but I'm wondering if there are any suggestions for something that installs getters for hash keys dynamically and is Moo-friendly.

Thanks!

It's common knowledge that on Windows, a line of text generally ends with a \r\n characters sequence, and on a POSIX system a line of text will end with \n.

Less well known is Perl's support for the escape sequence '\R'.

What's \R?

It's definitely not the inverse of \r.

It's a pattern (so for now its only useful in regexes) that matches Unicode's TR-13, The Unicode Consortium's guidelines for what counts as a newline. It's useful in a regular expression to match \r, \n, \r\n, or a few other character sequences that are used to represent newlines, so you don't have to remember them. It's worth noting that it is a character sequence, not a character, so it doesn't really make sense in a bracketed character class.

In my last post I identified three MooseX modules that might help me out and end the perhaps some tedious typing and bring a more structure design into my ADD game. The first of this is MooseX::Abstract::Factory.

Despite its name it does not actually create 'Abstract' classes in the sense of a class that cannot be instantiated like a 'Java Abstract Class'. I guess what they mean is a 'Factory that is Abstract' i.e. not tied to any one class or name-space.

So of you might remember this post some weeks ago where I came up with a huge org-chart of all the different roles they I thought i would need for may AD&D characters.

Well I was just now getting into the actual instantiation of characters and having them do something well I ran into a number of differing choices that I sort of discussed here on this post. I found that the visitor pattern worked very well for character creation (that one is almost all wrapped up) now that I am getting to the other side of the game I have t0 make a choice of which design or pattern to use.