If, like me, you do not speak Russian, following is the uncensored version in English.

When I was in junior high school there was a programming course offered off school hours. I joined it and learned some basic programming. I didn't really study with the class, I just had fun by myself. Then in the 10th grade I went on computer-oriented studies at school. We studied Assembly, C and Pascal. I actually didn't enjoy learning at school so I was behind the class. At some point I went and bought "A Book on C" and learned by myself instead of in class. When everyone else started the high school project I had already finished it. While everyone wrote a small snake game (we received a basic DOS graphics library to use), I wrote an encryption algorithm implementation cross-compiled for Windows and GNU/Linux with command line interfaces (I had used ncurses on GNU/Linux, specifically).

- What editor do you use?

I currently use Vim without any plugins or special features. except its excellent syntax highlighting and a few comfortable little tweaks. I tried several plugins but eventually removed them. I find IDE configurations confusing and disruptive. When I need to hack some Perl on Windows, I use Padre, the Perl IDE. I don't really give a shit about editor/IDE wars. Use what you find comfortable, and hopefully try out new things once in a while.

- When and how have you been introduced to Perl?

When I was in high school I met a hacker at hardcore punk shows who programmed in Perl. He was really cool and suggested I give it a shot, so I tried it and had a blast. Been using it ever since!

- What are other programming languages you enjoy working with?

I used several languages throughout the years (notably Assembly, C, C++, Ruby and Python) but honestly, the only language I really enjoyed working with is Perl. C was fun too, but from a different direction, I guess. Perl definitely takes the cake... err.. or onion.

- What do you think is the most strongest Perl advantage?

Technically-wise? Elasticity. Perl is not just flexible, it's elastic. You can move walls around, you can bend them, it's like the fucking matrix! Devel::Declare is just a reminder that literally anything can be accomplished in Perl. You are mostly limited by your own imagination.

I think what draws me and developers like me to Perl is the easiness of accomplishing things in Perl, since it just bends the world to your point of view, whatever it may be. So, if you can speak it, you can write it in Perl!

- What do you think is the most important feature of the languages of the
future?

Parallelism and community, hands down. At least to me.

Speed of execution is important, surely, but proper parallel execution seems to me like it's becoming more and more important. I reckon that's why Perl 6 has put so much weight on that.

Still, as much as parallel execution and speed are important, there is a limit to how involved you are when all you have is syntax. I mean, having a great language is... great, but having a community around it gives you a sense of belonging, which is one of the most basic instincts and desires we have as animals. We want to belong, to be part of something, to create for ourselves, for others, with others, and see it blossom and take shape. We want to exist and create existence. Community is exactly that. If we want a language that is sustainable beyond its technical capabilities, we need to have a good community, to make it more than just a logistical assortment of characters. It needs to be about people.

- What drives you in being so active in Perl community and open source in
general?

Several things do:
1. I like creating. The first time I picked up a guitar, I didn't learn a song, I tried writing my own. I wanted to create something new. Open source and free software promote that idea. They say "let's make something!" - Perl is centered around that. Perl always says "don't be afraid to try, don't be afraid to fail".
2. I like complaining about things and fixing them. I've become very good at pointing at things and saying "that sucks", and I'm improving at trying to fix things that suck. Open and free code allows you to do just that. It pushes you to get involved. Perl is a tremendous example of getting people involved. If you look at how many Perl programmers are working on more than one or two or ten or more projects at the same time, it's quite stunning. You get people involved in over dozens of projects throughout a single year. It's absolutely crazy. Look at rafl! He's everywhere!
3. I like cooperating with people. If there's anything more motivating, it's the ability to work with others. I get to cooperate with the smartest people I've ever met. Perl has some of the greatest minds out there. The vast majority of them are pretty fucking awesome people and I'm thrilled to have met them and be considered a friend to at least some of them. There's generally something very exhilarating about working with others towards a common goal. It fills you with purpose and satisfaction.

- You seem to write lots of async code. Why did you choose AnyEvent while
everybody else bashes it?

I actually started with POE. When I tried to wrap my head around it, a long time ago, I went to the IRC channel and asked. People tried to get me to write an event loop to understand it better. This one person, after an hour of me doing random things, asked me "what don't you understand exactly?" He worked with me for a good half hour explaining POE, and helped me understand it. I later found out it was Rocco Caputo, the creator of POE.

I decided to try AnyEvent because of its slimmer interface and better speed. I still like POE (and Reflex looks impressive) but it's a bit too verbose for me. I will probably get to work on some Reflex stuff in the future though, and I'm excited about that.

I haven't noticed people bashing AnyEvent as much as expressing disdain for the way the author (Marc) has occasionally expressed himself and at least one decision to break a module that he considers misusing the AnyEvent API. I'd rather not get into it too much, except that I agree on some things and disagree on others. Besides, there's a lot I don't know about it.

The only thing that troubles me is that AnyEvent didn't pick up as a community. I hope that will change in the future.

- You've joined the Dancer project quite early. Why do you think it attracted you?

Few things: how small it was, how thin the interface and DSL were and how warm the IRC channel was. Back when I started, there were three or four people in the channel, if I recall correctly.

When I wrote my first program with Dancer, I thought it couldn't handle CGI (I didn't even grep PSGI yet) and I wrote a blog post saying "too bad it can't, it looks kind of cool". That evening I went to eat hummus with my girlfriend and spent a few minutes checking online if someone had tried Dancer with CGI. I saw a post by someone saying "Sawyer wrote about Dancer and that it doesn't support CGI, but it does. This is how you should configure it!" - that was Alexis Sukrieh, who wrote Dancer. I was pretty amazed that he saw my post and had written an entire post back. It was so cool. That's when I joined the IRC channel.

The ease of helping out in Dancer and working on it with others was very compelling. You were a part of it as soon as you stepped in, and that just made me feel so wonderful working on it. People in the community are kind and thoughtful, and you always feel like investing time in Dancer is worthwhile for the Dancer users community and for the general Perl community.

- Tell us about your role in TelAviv.pm and group in general. Do you think
community meetings are important?

There had been a few organizers to Israel.pm, prominently Shlomi Fish and Gabor Szabo. After Shlomi decided to step down from organizing the meetings, I decided to try and organize it and boost the attendance. I called it TelAviv.pm because we met at the Tel Aviv university. Pretty quickly though we moved it to a place in Ramat Gan, which is 20 minutes from Tel Aviv but has its own municipality. I still kept the name anyway, since it's like a part of the larger Tel Aviv area (which is silly, since Tel Aviv is really small to begin with). I set up a crappy website (later revamped to a good website) and contacted people to give talks and gave quite a few myself as well. For the past few years I've organized the meetings, occasionally assisted by Shlomi or Gabor, who are both still active members in the community. The past few months we've decided to have each meeting organized by someone else. It was very successful. We have also successfully organized two fantastic Israeli Perl Workshops.

I think community meetings are extremely important! By going to meetings you can:
- Improve your knowledge of the language and its third-party modules
- Learn tricks of the trade
- Meet potential co-workers and employers
- Practice giving talks
- Making friends and possible cooperators
- Get free help with work or ideas you had
- Have a good time

It sometimes seems like it's not worth it, but once you start attending, let your guard down and meet new people, you begin to realize how incredible it is. It's like a free drug that makes you feel better, become smarter and better at your job without any side-effects except loss of time. :)

- You tweet a lot about your git experience. What is so special about this vcs?

Git is one of the best tools for any creator, whether a writer, a programmer or even a graphics artist. Sure, there are other tools, but they all suck in comparison. Git is small, fast and powerful. In a way, it's like the Perl of version control systems.

- You've visited Romania recently. What did you do there?

I had the honor of attending the Cluj.pm anniversary meeting. I gave a few talks and hung out with great people. I've written a detailed report available here: http://blogs.perl.org/users/sawyer_x/2013/03/clujpm-anniversary-meeting-report.html. In a nut-shell? Go there! Meet these people! Attending their conferences! We all have so much to learn from them!

- Your talks at the tech events are very positive and energetic. What's your
secret?

Thank you. :)

I guess I just think that what we have in the Perl community, both technical and social, is so fucking great, that it's hard to hold back.

There are so many exciting and fun things in Perl. When you look at other communities, at other languages, it doesn't seem like they have any glaring advantages (and many them don't have any advantages at all) but they know how to get excited about what they have. They show you some module that you know already exists in Perl for 7 years, but they get really worked up! In Perl you can write something amazing and people will just reply with a calm "cool" and that's it. We need to get worked up, we need to get excited, we need to realize how fantastic what we have is and to be ecstatic about it!

Another considerations in how I give talks is that if the talk isn't fun, you don't really learn much. It's hard to stay focused when it's just raw material. On a technical level it might be interesting, but you have to present it in an interesting and compelling manner. Look at Paul Fenwick and his talks. Can you imagine anyone not listening to him and learning from him? So of course none of us can be Paul (even Paul works very hard to be Paul), but we can do a hell of a lot more than just presenting a piece of code. We own our conferences and meetings, don't we? Let's have fun with it!

- Where do you work right now? How much of your time do you spend writing in
Perl? You've mentioned somewhere that you're an administrator too, is that
still true?

I currently work in two companies: an e-commerce platform and a VoIP startup. I'm fortunate enough to have an amazing boss that lets me to work on a ton of Perl. I started with 50% of my time on Perl and 50% on systems administration. Once I stabilized the infrastructure, I was able to program more of it in Perl instead of chasing my own tail (which systems administrators do a lot). That way I got a stable ground and then started writing major components of the infrastructure in Perl. Nowadays about 80% of my time is spent writing Modern Perl, as part of the infrastructure and surrounding services.

At least until recently, because in June I will be moving to Europe and will be taking a different job. I will probably blog about it when the time is right.

- Should we encourage young progammers to learn Perl?

Definitely! We just need to know how to be fucking excited about it. It takes time to realize why a certain solution is elegant, why a piece of code is nothing short of a work of art. Hell, it takes time for all of us to understand. Young programmers, who have even less experience, do not easily understand why Moose is spectacular. We need to be able to convey this. We need to be able to draw their interest in more than our experienced background, but in their inexperienced view. We need to speak their language and get them hooked. They will slowly learn to appreciate things from a more refined aspect, so we shouldn't worry about that now. Now, we should get them thrilled, get them interested.

Questions from our readers (some of them are jokes :):

- Is Sawyer your real name?

Actually, No. It's a nickname my closest friends gave me a long time ago. It comes from the fictional character Tom Sawyer. There is a story behind it, but I'll keep that for another interview. :)

If you're ever unsure about calling me Sawyer, think of it this way: I always prefer to make a friend, so feel free to call me the way my friends do!

- Why do you swear as 5 yo?
(note: this is in regard to a comment I made at YAPC::NA 2012 saying "I was swear like a 5 year old")

That was a slip of the tongue, I'll admit. I meant to say "13 year old". I guess swearing is one of the instruments I use to put emphasis when speaking. I mean, it's fucking noticeable! I also grew surrounded by trashy American action movies and profanities in Israel are generally very common, so I suppose my speaking patterns adjusted to all of that. Horrible, isn't it? :)

- So, did you have a drink with Sebastian Riedel?

Not yet. I certainly hope to do so!

I got to meet Glen Hinkle who's a charming person. I hope next time I see him I'll be able to sit down with him some more and chat.

- Are you going to visit YAPC::Europe in Kiev this year?

I was supposed to attend, then couldn't, and now there's a chance I might be able to attend anyway. I can't make promises because people get mad at me when I cancel, but it just might be possible for me to attend in the end. The question is how late could I submit talk proposals. :)

Pinto is just that. Pinto is such a useful utility that it makes it easier for companies to use Perl more intensively. It allows anyone (whether a company or a single programmer working on personal or contract work) to easily maintain a CPAN-like repository of Perl modules, whether from CPAN or not. It helps manage this repository to add new company modules, new CPAN modules, pin versions, upgrade and so on and so on. It basically makes it possible to effortlessly maintain your own CPAN, within the workplace (or home) while still using modern tools like cpanminus.

Considering a major issue for companies is keeping code uniformed, properly stored and comfortably installable, Pinto provides a crucial service in an elegant and graceful manner.

Supporting Pinto means supporting more Perl Awesome Sauce from a developer who had already contributed greatly by giving us Perl::Critic.

Toolbox Investment

I think of Pinto as more than just nifty. I think it is going to be a crucial centerpiece of any proper environment. I can't think of a company I worked for, that had proper Perl code, that wouldn't have a use for Pinto. Instead, any company I think about could use it. Any company I worked at could have utilized it to make their work (and my work!) much easier and much more flexible.

I'm certain that in the future we will see Pinto's proper place in our immediate toolbox. Why not invest now? Why not make sure we'll have a great tool?

Community Outreach

I'm pretty certain that it wouldn't be difficult to get more funding to Pinto via companies, TPF grants, EPO initiatives, and other such methods. The major benefit to crowd-funding is that you get the community to wake up and step up to the plate. If all Perl users would be part of the community, we would be so much bigger, but we suffer from what I would call a "woodwork syndrome" which is a bountiful of people who are not part of that community. However, many of these people are in-tuned to other websites. This includes Slashdot, Digg, but not only news websites. Some of these can be crowd-funding websites like Crowdtilt and Kickstarter. Some of these are websites that write or tweet about projects that get crowd-funded.

By getting this project funded, you're notifying the world on a lively Perl project and community. You're advertising your language and your language's awesome sauce to the world.

Opening Your Own Door

Most importantly, Pinto is not the only project that could (and should) be crowd-funded. There are plenty of others. Pinto is just the beginning. Since your project could be next, wouldn't you want to have a good beginning? Sure you would! This is why you should chip in a few bucks ($1 and up) and help us all, as a community, fund this today, and hopefully yours tomorrow!

Hey, look at that! Here's the link again!

See, you probably don't know what you want to do yet, and that's fine. It takes time for all of us to finally understand what we want to do. The great thing about Perl is that whenever you're ready, and whenever you know what you want to do, Perl is there. Perl is a language that allows you to take your time in deciding what you want to do, and when you finally know what it is - you could use Perl for it. It will just work.

Perl has a wide variety of modules written by people like you and me. There's the CPAN (Comprehensive Perl Archive Network), which is where we upload all of these modules. Anyone can join, anyone can contribute. You get free support, an issue tracker, a testing framework, and everything. You get people to help you out, and improve your code and knowledge and understanding, and you get to help other people. It's incredible. No other language has this much third-party components. It really is crazy!

But Perl is not just a strong, fast, open, free, and incredibly flexible language, but it also stresses community. You'll notice I don't speak Romanian. That's because I'm Israeli. I came here for a Perl meeting. Perl has lots of meetings and conferences. Perl has the most conferences world-wide than any other programming language. This isn't by accident. It's because we care about community. We have close to 4 big conferences (400-900 people) and dozens of conferences of smaller magnitude of 40-120 people - just about Perl. We meet, we drink, we talk about stuff, we even learn and teach each other new skills. We form not just professional connections, but actual friendships. We're all friends, and it's very rare, and very special. Nothing really can compete with that.

Perl is not just a profession or a skill, it's a home.

I've been consistently surprised by the amount of work and care done by Evozon in organizing the Perl meetings of Cluj.pm. They advertise it well, they invite guest speakers, they design and print out custom nametags, pick selective locations that could host everyone, sponsor drinks, etc. Hell, they even provide complimentary beer with a custom label relating to the event ("A camel walks into a bar..."). Oh yeah, and prepared a fantastic cake of the group logo I was given the honor to cut first.

I gave three talks at the event. I was told they were successful, first by people who cynically thanked for being placed after my talks with a friendly poke, and second by actual feedback pages. Yes, you read that right. Cluj.pm meetings have feedback input! You list what you liked, what you didn't, and what you would like to see, and you rate your experience, the event organization, the speakers and the subjects - just like with YAPC.

I kept hearing from the organizers that they're still a young group and they have much to learn, but they're in the right path. Some of you might be thinking if there is something they've done wrong. No, none. They've actually got so many things right, I think it's crucial to list at least some of them:

• They found an awesome venue


• They get (and sponsor) guest speakers


• Promotional material like nametags, beers


• A freaking cake!


• Feedback from attendees


• They have multiple female speakers and multiple female attendees (yes, it's important!)


• Multiple people (including female) giving their first talk (they use incentives to get people to try - it's brilliant!)

The evening was a great success. I had a blast! The talks were interesting, the speakers were fun, the audience was warm and welcoming. We stayed up until a late hour, chatting, rambling, drinking, eating and having a very good time.

The following day I got to speak in front of students at Evozon. They have an intern program that allows students to apply to Evozon (without dropping out of school), possibly be hired and do an internship. Afterwards they might find a permanent job. I was asked to speak about Perl, hopefully providing the students with incentive to consider the Perl department for their internship application.

I started with the fact that most of them probably don't know yet what they want to do, whether it is web programming, networking, security research or even graphics, but whenever they will, Perl will be a useful language to know, and they could utilize it for whatever they chose. I explained about the strengths of Perl, but the bottom line was, really, its community. You don't just create professional connections, you form actual friendships. My main point, in a line, was: Perl is not just a profession or a skill, it's a home. I was told the applications for Perl afterwards spiked, by students who had only heard about the language for the first time. (perhaps some was due to an example I gave on making 708,000 requests in 6 minutes to find actors across 42 seasons of 6 TV series)

If you think I was exaggerating about the comment on the Perl community being a home, a good demonstration of it is my time in Cluj. Every single day people from Cluj.pm had made it their mission to make sure I don't get bored, hang around with people instead of stashing myself at the hotel, go out and get some air and see the city, have a good time. They kept me company and made countless efforts to make sure I had everything I needed and more. It was quite overwhelming and touching. I truly felt I had made new friends who care a lot about me.

I had an incredible time, and I owe a huge thanks to Evozon, to Cluj.pm, to Amalia, Anca, Darius, Horea, Natasha, Mircea, Mihai, Diana, Raluca, Mirela, Marius, Arpad and at least a dozen other people who made my experience simply delightful. Nothing echos my message to the students about community as much as the wonderful treatment I received.

I already miss it all. :)

Fortunately for us, we are lucky to have such skilled, cool, and handsome people as Stevan Little and Paul Evans, to implement Promises and Future, respectively, for us in Perl. Nowadays for my more complicated projects, I use Promises with joy. Stevan and Paul, each in their developed modules, have provided numerous examples (and introductory text) to how this pattern works and how to use it in various situations. Also, they are (as always) more than helpful when asked for pointers.

Letting go of my crush of Stevan and Paul for a bit, I'd like to explain a specific issue that troubled me in a project, which lead me to write recursive promises. What is it, why did I need it and how did I accomplish it? I'll be using the Promises module, though the principle is exactly the same as in the Future module.

I have a project which deploys a new server. This requires raising a ticket to create an instance, monitoring the status, and then running commands on it sequentially. First command updates, the next installs some prereqs, the one after that installs the deployment infrastructure and the last one is run locally to deploy our code to the server. This clearly leads to the arrow-head format:

run_remote_command $host, 'aptitude update && aptitude safe-upgrade', sub {
    # check possible fail or succeed
    run_remote_command $host, 'aptitude install build-essential curl...', sub {
        # check possible fail or succeed
        run_remote_command $host, 'gem install chef...', sub {
            # check possible fail or succeed
            run_local_command 'chef solo cook ...', sub {
                # check possible fail or succeed
            }
        }
    }
};

Not so pretty, is it? Well, I can use promises to make it more manageable:

use Promises 'deferred';
my $def = deferred;
run_remote_command $host, 'aptitude update && aptitude safe-upgrade', sub {
    if ( my $result = shift ) {
        $def->resolve($result);
    } else {
        $def->reject("Failed update/safe-upgrade");
    }
};

$def->promise->then( sub {

    my $def = deferred;

    run_remote_command $host, 'aptitude install build-essential curl...', sub {

        if ( my $result = shift ) {

            $def->resolve($result);

        } else {

            $def->reject("Failed update/safe-upgrade");

        }

    } );

    return $def->promise;

}, sub {

    my $error = shift;

    die $error;

} )->then( sub {

    my $def = deferred;

    run_remote_command $host, 'gem install chef...', sub {

        if ( my $result = shift ) {

            $def->resolve($result);

        } else {

            $def->reject("Failed installing chef");

        }

    } );

    return $def->promise;

}, sub {

    my $error = shift;

    die $error;

} );

...

You get the idea, right? Create a deferred promise, resolve or reject it later, and pass back the promise itself. Use the promise returned to chain more promises with deferred promises that resolve or reject later. Very nice. If you have a hard time following this, try this cookbook.

My problem was having to hardcode all the commands and have a known list of commands in advance, in order to write a promise step for each. You cannot have an arbitrary number of promises steps. At least not too easily. I wanted an array of any number of commands that will be run separately in each promise step. My solution was a recursive deferred promises pattern (at least that's how I'm calling it for now - trademarked!), illustrated in this Github gist:

As you can see, I set up the first promise and chain it to a code reference that calls itself recursively until the array of actions is exhausted. A good point made by Nicholas Perez was that instead of defining a variable for the callback and only then defining it as a coderef (thus allowing it to call itself), I could have used the new __SUB__ option more modern Perls (since Perl 5.16) have. In production my code has to be more backwards compatible, so I had to use my method instead.

Epilogue, sort of:
The one thing I want you to take from this post is not that I'm cool (although I am, very much so - you should definitely consider being my friend), but rather that when we talk about creating cool stuff (re: John @genehack Anderson's talk on this), we talk about stuff like Future and Promises. That's an example of writing something awesome, even if we didn't invent the concept. If you look at the code of Promises, for example, it's not even complicated or hairy. It's short, clean and elegant, and it provides a great service for programmers, and a wonderful standing point when we want to promote Perl as a strong and modern language. "Futures/Promises? Oh yeah, we got that!"

Here's a description of what it is, what the improvements are, and some of the considerations in doing them.

It's a Moo/Moose role (works with both) that allows you to provide comfortable and strong logging capabilities to your objects. It uses Log::Dispatchouli to allow you to connect to various logging outputs. You can work with files, stdout, stderr, and Syslog. It has levels, facilities, identity, debugging mode, muted logging, fatal logging, and control over the path and name of the log files (if that's what you chose to use).

Along with methods (such as log and log_debug), it provides attributes with sane defaults to allow your application to work without doing any additional work. For example, you get a debug flag and the log_debug method will only output something if the flag is on.

Changes introduced:

Other than documentation improvements, I've introduced two major changes: setting the logger_ident attribute automatically and deprecating the log_fields method.

The identifier:

The logger_ident attribute is the application's identifying string for the logging. The default was set incorrectly to the name of the role, instead of the name of your class. Now it is set correctly to whatever your application's class name is.

If your have an application called MyApp::Worker, and it uses the role, the ident will be set to MyApp::Worker. This makes all logging instinctively clear for you in all your logs.

Of course, you can always set it to whatever you want by overriding the attribute in your class.

The logger fields:

Sometimes you have object MyApp, which uses the logger role, and you want to create another object (say, MyApp::Worker) which needs to have the exact same logging capabilities. The method log_fields was added in order to provide all the configuration for the child object. That wasn't very smart.

Instead of passing the attributes, you can simply pass the logger (Log::Dispatchouli) object, available in the logger attribute, as such:

MyApp::Worker->new( logger => $self->logger );

However, this created a problem. You see, MooseX::Role::Loggable provides attributes which are then used to create the logger object automatically. They have their own defaults as well. If you provide a logger yourself, you're ignoring the attributes, and the attributes no longer reflect the object you have passed. That's the problem.

MyApp might have the debug flag set to on. If it passes the logger to MyApp::Worker, it will have a debug-mode logger, but MyApp::Worker's debug flag attribute will be set to the default, which is off. The logging will work, yes, but probing your secondary object (like checking its debug flag) will be incompatible with what the logger actually has.

$worker->logger->{'debug'} == 1; # true
$worker->debug == 1; # false, uses default value: 0

The way to fix it was to check whether a logger was passed to the object and if so, change the values of the attributes in the object to match the ones defined in the logger object that was passed. I used the BUILDARGS method for that.

Another tricky corner is making sure that you still allow the user to provide a logger and to override something in that logger. For example, a user might want to pass the logger, but enable debugging, which isn't on:

$self->debug == 0; # true

# pass the logger, but also turn debugging on

MyApp::Worker->new( logger => $self->logger, debug => 1 );

This sacrifices the immutability of the logger somewhat (and I'm a *big* fan of immutability) but I think that's a plausible usage case, so I'm allowing it.

If you're already using the log_fields methods, you should stop. It will still work now (passing on the logger attribute for you), but it's deprecated and will emit a warning both in your terminal and in your logs. Why both? Because I have no idea which is active, and I want to make sure you don't miss it, because will remove it later on.

The code looks like this:

my @acl = map { $_->ipAddress }

          map {

            VM::EC2->new( -region => $_->regionName )

                   ->describe_instances(

                       -filter => { 'tag:Name' => 'worker' }

                   )

          } VM::EC2->new->describe_regions;

We create a new VM::EC2 object, and call the describe_regions method, which retrieves the list of available regions in EC2. Then we go over reach region and create a new VM::EC2 object for that region and search for all instances that match a specific Name tag. Then we access the ipAddress attribute to get the public given IP address that EC2 has given that instance. It all funnels into an array, so we end up with an array of IP addresses.

Enforcing the ACL
NOTE: this could also be done using Plack::Middleware::Access, but it still provides some insight into Dancer, and gives you more finer-grained control over the result.

To make sure Dancer enforces the ACL for each and every request, we simply add a before hook that checks if the IP is acceptable. If it is not, we return a Dancer::Error response.

This is what Plack::Middleware::Access does, but if we wanted, we could go beyond and log it, and forward it to a login page which will create a cookie and start checking for that cookie in the before hook, or... well, there are a lot of ideas. I'll leave them to you.

The code looks like this:

hook before => sub {

    my $address = request->remote_address;


    grep { $_ eq $address } @acl

        or return Dancer::Error->new(

            code    => 403,

            message => 'Access denied',

        )->render;

};

Enjoy.

While trying to work with Icecast, he found that there is no Icecast 2 API on CPAN and decided to write one. As usual, he writes Modern Perl with all the usual bells and whistles: Moo (+ Sub::Quote), MooX::Types::MooseLike, read-only attributes, documentation, Dist::Zilla and so on.

It's on Github to hack on, and I assure you he is very cooperative. Feel free to help out, suggest improvements or offer any criticism.

no ident specified when using Log::Dispatchouli at Loggable.pm line 117.

I keep running into this and resolving this each time without remembering what this means, so I keep having to debug it all over again. While I've documented this issue in the new version of MooseX::Role::Loggable, I'd like to explain it here as well.

MooseX::Role::Loggable adds a lazy attribute for Log::Dispatchouli. If you don't call any logging method, you will not pay for the extra of Log::Dispatchouli (except the "use" statement for loading it). That attribute depends on other attributes which aren't lazy, but still might get inflated only after whatever attribute whose builder calls a logging method. Wait, let me rephrase!

You have a db attribute which has a builder that connects to the database. You add a log_debug method before it just so you can debug when the database is being connected. It looks like this:

has db => (
    is      => 'ro',
    builder => '_build_db',
);

sub _build_db {

    my $self = shift;

    $self->log_debug('Connecting to DB');

    ...

}

You call log_debug which calls the builder for the logger object, which now depends on the ident attribute, which... oh my, it hasn't been inflated yet. Damn!

The solution is simple: you make your attribute lazy, and then call for its inflation right after compilation phase, in the BUILD method.

has db => (
    is      => 'ro',
    lazy    => 1,
    builder => '_build_db',
);

sub BUILD {

    my $self = shift;

    $self->db;

}

That will make sure that all non-lazy attributes are built before your db builder is run. Viola!

Hope this helps anyone who stumbles upon this. :)

I was recently asked to add to Perlbal::Plugin::SessionAffinity the ability to allow consistent session affinity per domain. Hell, it's a paid feature so I took a look at it.

The idea is that if you have a lot of domains and you use Perlbal::Plugin::SessionAffinity in your Perlbal reverse proxy, you might get a fragmented cache because each user will reach a different (yet consistent) backend, regardless of the domain they requested. When someone has more than 300 domains behind the same reverse proxies (and let me tell you, some people actually do), this fragmented cache reduces efficiency.

So, now Perlbal::Plugin::SessionAffinity has a domain mode (which can be triggered by the affinity_use_domain configuration option) which returns a fixed backend for every client based on the requested domain. If the backend no longer exists (such as if, for instance, you removed it live from the pool), it will return a different backend - so you can still play with Perlbal live and it will not hurt the SessionAffinity module.

My client seems to have improved cache performance using this feature so far.

If you're using Perlbal::Plugin::SessionAffinity and find it useful, drop me a line. If you're using this feature, I'd be happy to get any feedback.

I won't go into the horror stories of people getting yelled at for saying Mojo doesn't support dependencies. Instead, I'll give my opinion on the concept of no dependency, and you could decide for yourself if it relates to Mojolicious or not. I honestly don't care. Obviously, this is not a "don't use Mojolicious" post. In fact, I think it's a cool framework and you should try it out. This post is about my general opinion on the "no dependency" idea. Mojolicious is an example, DBI is another, and there are definitely others (Moose, anyone)?

The whole "NO DEPENDENCY HEAVEN!11" approach to me seems like the PHP "we embedded the code in your HTML!11" approach. Basically, doing something that tries to handle the current situation but in a way that actually ends up counter-productive when technology advances.

Back in the day, web code printed out HTML code. That was horrible. CGI.pm tried to alleviate it by suggesting using functions instead of hardcoded HTML tags. It wasn't much better. Then PHP came along and said "hey, let's just embed the engine code inside the design code!" - everyone was happy. Then we realized HTML coding is actually outside the scope of engine coding (and vice versa), so they were separated. We created templates and had engine code render them using variables. Neat! But now PHP is actually an HTML document that only opens a PHP tag, that runs code that opens a different HTML document, which is an HTML template, and renders it to HTML. That's how all PHP applications are. Suddenly it ain't cool no more. Suddenly it's stupid.

The "no deps" camp (whether in a web framework or elsewhere) tries to handle a similar problem (which is actually temporary, and constrained by technology and willingness), which is the ability to include additional code. It's hard to change willingness (a point which Ovid expresses eloquently), but technology is more manageable. Including dependencies is no longer a hassle: you have local::lib, FatPacker, Carton, cpanminus, perlbrew and Plack. Nowadays, including additional code is actually very easy. In fact, some technologies (such as cpanminus, perlbrew and local::lib) made it extremely easy to install new code instead of bundling it. But hey, you can do both.

Mojolicious is one of the few projects that have such a skilled core team (and lead developer) that they actually can rewrite the entire core, including any required dependency from scratch, and do a damn good job. Unfortunately, this is not the case with most other developers. In fact, even very skilled developers (and there are a ton in the Perl community) prefer not to spend their time rewriting something that is already (possibly, plausibly, probably) well-written, even if they can do an incredible job at it.

This lays the beginning to the consequence Ovid mentions: people are learning from the "zero-dependency" concept to be zero-dependent. They actually start to abhor dependencies. I've seen people coming from that camp try to rewrite DBI. Yes, I really did see it. It was horrible and expectedly it failed.

So what does zero dependency really means? To me, it means you either don't support a lot of features, or have numerous possible bugs, or have rewritten a lot of things, or you don't know how to bundle your stuff, or don't know how to setup Pinto (or you don't understand the reasoning for it), or you don't understand the idea of reusability, or that you're incredibly arrogant thinking you can do better than everyone (and frankly, a few can), or... well, a lot of things which are generally not good practice, by any fair standard.

I honestly don't intend to work on projects that require me to use zero dependencies no matter what. It's a serious - in a term Ovid proliferated - code smell.

Remember, the excuses of "I don't have permissions to install new modules" or "I can only upload stuff here" are no longer relevant since we have tools to bundle stuff, pack them, install them locally and more. Those situations are no longer a problem.

In short: with time, technology changes, and we should have an approach that isn't locked on a certain approach that might change as technology advances.