This is a response to Chromatics blog post Would You Miss Autoderef in 5.20?, because I can’t ever get comments to work on his MT for something like a year (500, or some blogger openid incompat). In all honesty I don’t find either particularly interesting. I’ve too often been targeting 5.8 or 5.10 for syntax… @{ $foo } is really the most I’ve ever needed,@$foo is nicer, but beyond that don’t need it.

So when I started using Dependency Injection the following problem happened, how do I Inject this dependency when the container is not accessible at this point. Ok, that sentence even confused me a little bit, so what do I mean. Let’s say I have a Repository for Products that is injected into my controller. Each Product stored has one or more ProductVariants that is part of it’s aggregate, which itself has Nested Categories.

So I’m thinking of proposing some talks for YAPC::NA Orlando, and/or maybe do some training. Here’s my thought on what I could do that would be a contribution and different from other talks. For Training it might just be a combination of all of the concepts I could do as individual talks. Basically the idea is “I’ve learned Perl and Moo[se], now how do I build a large application”. UML SOLID Object Oriented Design Design Patterns Domain Driven Design Patterns of Application Architecture Service Oriented Architectures, REST, ROA, RPC (including RESTful RPC and Resource Oriented RPC), and Pub/Sub ORM Patterns ( Active Record / Data Mapper / Transaction Script ) MVC Layered Architecture Ports and Adapters Dependency Injection ( with Bread::Board ) Let me know your thoughts.

Just before my abrupt departure from my former employer, I took over maintaintership of Pod::Spell. I have started working to clean up the code, add modern and more tests, and improve the wordlist. There is much to be done on this front. More tests are needed yet, to ensure no accidental breakage. There’s possibly a unicode bug lurking within Pod::Spell. More words are needed for the wordlist. Patches are welcome as I don’t have all the time in the world to work on it.

File::chmod has been around for a long time, and is really stable, and really hasn’t changed since 1999. It is far more user friendly than thechmod() in core Perl. I recently used it for an interview test. It took me a few times to get right however because it’s default behavior in symchmod() mode is to use the systems umask. I find this to be very confusing behavior. I actually thought it was a bug at first, and asked for comaint since it hadn’t been updated in so long.

Moose interfaces are problematic, for 2 reasons. They are compile time, but runtime features such as attribute delegation could provide the interface (role ordering is the real problem here) They don’t ensure anything other than the method name. I think this problem can be solved better by using around instead of requires 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 package Interface::Create; use Moose::Role; use Type::Params qw( compile ); use Types::Standard qw( slurpy HashRef); around create => sub { my $orig = shift; my $self = shift; state $check = compile( slurpy HashRef ); my ( $obj_args ) = $check->( @_ ); return $self->$orig( $obj_args ); }; 1; Ordering of course still matters here as you can have multiple around modifiers on a method.

If you’re not familiar with the term “Inversion of Control”( IoC ) or “Dependency Injection” ( DI )you may wish to start with Martin Fowler’s post on the subject. If you’re looking for a way to do it with Perl, Bread::Board is the way to go. This post however is about the theory behind it, and a path to grokitude if you’re finding the concepts challenging. I should advise that I am not yet a buddha on implementation.

I had this problem for a long time, and no one ever proposed a good solution. Recently I got a new answer on my, almost 2 year old, Unix and Linux StackExchange question. This information seems very obscure and so I thought I’d share it, if you too have had this problem and were unable to find this, or at least found finding it hard, consider upvoting the answer. Problem You’re using a Linux system that you don’t have root on, you need to override the DNS of the system.

What is Interface Driven Design? Interface Driven Design simply means that you should design your software around a flexible, easy to use, easy to understand interface. This is easy to achieve if your objects are of SOLID design. There is a simple table and reference link if you’re not familiar with the principles. My Work is SOLID already Then you’re on the right track but it’s not enough if you don’t fully marry the concept to best practices.