As I have previously posted here, YAPC::Asia Tokyo is the world's LARGEST YAPC. Last year we brought 841 people together for the two day geek-fest. This year we're doing it again in the lovely Keio-University Hiyoshi Campus.

Why not come and mingle with the Japanese Perl hackers? If you use tools like Plack, Test::TCP, Parallel::Prefork, Mouse, plenv, etc then you're got to come talk to their authors! Meanwhile, we'll be even more delighted if you choose to give a presentation. Please submit your talk proposal here

Should you need more info/help, please contact @lestrrat on twitter. I'll be more than happy to help you get to this conference!

I purposely asked people spreading the news to specifically state that this was not just for hardcore Perl users, and that even if you did't use Perl much these days, I still wanted your input.

So over approximately two weeks I got 394 replies, and I've compiled the results in my blog. However, this is all in Japanese, and even with Google Translate, the outcome was pretty um, poor.

So here's a (terse) version in English so y'all can see. This will probably give you an insight into how the Japanese Perl community looks like, and what type of technology they prefer.

This probably means nothing if you don't know Japan, but this shows that the Japanese tech market and resources are extremely concentrated in the greater Tokyo area, with a whopping 74% of the respondents living in 関東 area.

Q. How long have you been using Perl ?

In the chart below "年" means "year". So 38.1% of the people have been using Perl for 10 years or more, 10.9% have been using it for 7~9 years, etc.

Q. What is your Perl proficiency?

I used a vague terminology here: In the form, 初級者 (beginner) was somebody who needs others to help you to write proper Perl code. 中級者 (intermediate) was somebody who can do more or less all you want to do, but you still need the aid of books and web pages. 上級者 (experienced) was somebody who can do whatever he wants, and if you don't know something, you just go and checkout the source code

Q. How much Perl do you use at work?

We asked to rate how much you use Perl at work. 10 means you use it all the time, and 1 means you rarely use it.

Q. How Much Perl Do You Use For Projects Outside Of Work?

Same as above, but for projects that you work on outside of work

Q. How Do You Manage Your Perl?

We asked how you manage your Perl installation. Multiple answers were allowed. In the chart below, "システムPerl" is "System Perl" i.e., stuff that you install via rpm, deb, and other variations that are pre-installed with your OS. "自前でカスタマイズ" literally means "Hand-rolled", but in this case we mean "You build your own Perl"

Q. What Operating System Do You Use Perl On?

I think this is self-explanatory. Multiple answers were allowed. "その他" means "Other", so "その他 Unix" is "Other Unixen".

Q. If You Use Perl On Windows, Which Platform Do You Use?

I think this is self-explanatory

Q. What Do You Use Perl For?

Multiple answers were allowed. This was a vague question. Basically we wanted to know if you used Perl for web-based stuff, or others. The choices were "Web Apps", "Server Management/Configuration", and "Data Processing"

Q. Which Perl Version Do You Use The Most?

Ditto. There seems to be still a relatively large number of people using Perl < 5.10

Q. Are There Other Versions Of Perl That You Use?

Multiple answers were allowed. Looked like most people use multiple versions of Perl.

Q. How Do You Install CPAN Modules?

cpanminus takes a whopping 62.7% of the share. The second from last choice is "I don't use modules". Yes, these people exist.

Q. What Environment Do You Deploy Your Web Apps?

Multiple answers were allowed. Lots of CGI are still out there...

Q. Which Class Builder / Accessor Generator Do You Use?

Multiple answers were allowed. This should be interesting for English-speaking readers. A LOT (and I mean ALOT) of people don't use any class builder-llike tools. Class::Accessor::* family is preferred. Mouse is at the top of Moose family, and Moo and Moose are used about as much. Moose-family is NOT favored in the Japanese community. My guess would be that people in Japan prefer light+simple over big+feature full, which is also evident in the next question.

Q. Which Template Engine Do You Use?

Multiple answers were allowed. The whopping success of Text::Xslate in this category also shows how Japanese people prefer products that are geared towards speed.

Q. What Language(s) Do You Use Other Than Perl?

This should be self-explanatory.

That's it for now! If you find any interesting correlations, please let me know. Also, if you feel like it and you can wade your way through Japanese, the original data (anonymized) is available on Google Docs. Feel free to use that data, but if you do, please let me know.

In this post I'll briefly describe how I'm refactoring code using a little tool called Geest (github), which I completely stole from Ruby's kage.

tl;dr: With Geest you can check differences between new / old code transparently. It's really handy. Please let me know what you think, or file issues if you find any.

1. Read the code
2. Write some code
3. Check /very/ carefully

Of course, I'm trying to write tests while writing new features, but when you have no formal spec, it's extremely hard to write automated tests. Luckily most of what I'm currently refactoring is code to "view" the content, and not a whole lot of code mutation, so all I really need to make sure is that the contents render correctly. So at this current stage, it's much easier to check with your own eyes if that code you have refactored is doing what it used to.

And I know, at this point you are all like "WTF, write your tests first". Yeah yeah. While I can't share you the code, all I can say is "I will, but only after I kill all of this god forsaken mod_perl code". There are many reasons that makes it hard to test against this code base. So my current priority is to just fix the shit out of it.

So what to do now? Well, my goal is to replicate the output of the production server. i.e., I have the correct output being served from there, so all I need to do is to check that given the same request, I write code that generates the same content. This is where Geest/kage enters into the picture.

Firstly, kage is a tool written in ruby, and it does exactly what I'm going to talk about Geest. kage is a great tool, and it does what it does correctly. The reason I wrote Geest is because, well, why not. I wanted to port it so I know how this worked.

So back to my original problem of trying to test my refactored code: Let's say you have production.myapp.com, and staging.myapp.com. You deployed your new refactored code to staging.myapp.com, and you want to make sure all that new staff matches your old code base.

Geest is basically a simple proxy server. It receives requests from your browser or whatever, and relays this request to all servers that you specify. In my setup, I put Geest in front of my staging server, and configured it to check produciton.myapp.com AND staging.myapp.com. You might do something like this:

    use strict;
    use Geest;

    my $server = Geest->new();

    $server->add_master(staging => (

        host => "staging.myapp.com",

        port => 5050,

    ));

    $server->add_backend(production => (

        host => "production.myapp.com",

        port  => 8080

    ));

    $server->on(select_backend => sub {

        return [ qw(staging production) ];

    });

This tells Geest the following:

1. You have "staging" and "production" backends
2. Staging is considered to be "master", which means that response from "staging" is preferred when replying to the client
3. On every request, you want to relay the request to both staging and production

And finally, after the above, you can tell Geest to create PSGI app:

    return $server->psgi_app;

This needs to be run in a AnyEvent-compatible PSGI server, e.g Twiggy:

    twiggy -a app.psgi

After all of this is done, you can point your browser to http://staging.myapp.com:5000/. All requests will be relayed to BOTH production and staging. When responses come in from "master" (which is "staging") you get a reply. Well, that's nice, but it still doesn't check for differences between production and staging.

So then at that point you can go back to your app.psgi and add the "backend_finished" hook to check if the responses are in fact the same:

    use Test::Diff;
    $server->on(backend_finished => sub {
        my ($responses) = @_;
        # $responses = {
        #    name_of_backend => {
        #       backend  => ...,  # Geest::Backend object
        #       response => ...,  # HTTP::Response object
        #       request  => ...,  # HTTP::Request object
        #    },
        #    ...
        # };
        if (! $responses->{prod} && $responses->{dev}) {
            return;
        }

        my $data_prod = $responses->{prod}->{response}->decoded_content;

        my $data_dev  = $responses->{dev}->{response}->decoded_content;

        if ($data_prod ne $data_dev) {

            # You probably want to check that both responses are

            # content_type -> text/* before running diff()

            print STDERR diff(\$data_prod, $data_dev);

        }

    });

This hook is called after all of the backends have finished. As you can see, a simple diff() will get me the result I wanted. With this, I can be assured that the new code base is acting like the one in production. Yay! Mission accomplished!

So, in summary: Of course, it's better to have a perfect spec and automated tests in place before hand, but when push comes to shove, Geest is a good fallback.

Also, I'm sure you can do more with this. For example, you might change this to receive some of your traffic from production environment, but make sure to 1. make "production" the master backend, and 2) only send "idempotent" requests to the staging backend. This way you get to check your code base against live traffic.

Let me know if there are any problems, or please send me comments!

What seemed like a simple API addition in the end turned into myself writing a autoconf like "compile, see if it works, and check if a particular API exists" type of too (is there a CPAN build tool change component that does this kind of stuff?). I'm satisfied by the fact that it actually works, but I must say the Makefile.PL for ZMQ::LibZMQ3 is starting to get pretty darn wacky.

Then I had massive amounts of fun debugging its behavior on Travis CI, which at the moment had this pesky bug where your build logs don't come out until the entire run is done -- and when you have a matrix of 4 perl versions and 6 different components to test under a single run, it means you need to wait for like 20 minutes or so to look at them logs, even though you know from the beginning the run failed because you see a red light in there.

But anyway, so I've done it, I fixed a bunch of problems, added new, missing API. Check out the list of stuff that I added in the Changes file

While on that streak, ZMQ::CZMQ was split into its sugar layer and ZMQ::LibCZMQ1, which is the actual binding. I believe you had to be extremely lucky to have the old CZMQ perl binding to build, but now it should build.

Should you encounter any problems, please report at Github Issues. Otherwise, enjoy!

This change had two effects: for starters, the venue is operated by a very famous hotel management company, and so the service was just GREAT (check out photos of our social/free dinner below), but on the other hand the costs kinda skyrocketed. Well, we worked hard to raise enough money to cover the costs, and we didn't raise the conference ticket prices so in the end it was fine, but nonetheless...

Anyway enough about the venue. We'd been told to expect a typhoon to pass by Japan anywhere during the 3 day event, but a miracle happened and we were spared from having to hold YAPC during a storm. That also meant that we needed to expect the full list of attendees to arrive, which was, well, a lot.

As I've previously announced, based on ticket sales we had 743 attendees. If you include speakers, we had 798, and if you included the staff it was 841. Seriously, how we managed to pull this off, I'm not sure. But I do believe our efforts in the last 4 years are now starting to pay off.

Swag

This year we have gone over board with all the stuff we made. We made the official YAPC T-shirt, we made two colors for "I gave a lightning talk at YAPC" T-shirt, and for those people who individually sponsored us we made special T-shirts and mugs (seen in the picture above).

Of course, there were a whole bunch of stuff that we got from our 33 sponsors. You can look at all of that on this entry (the page is in Japanese, but you just need to look at the pretty pictures, so no problem :)

Day 0 / RejectConf

Day 0 was RejectConf. We had three talks, and also some snacks for the people to enjoy. Apparently the noise from the crowd was a bit loud, but this Day 0 event is supposed to be a very informal session, so... hopefully it was quiet enough for people to follow the talks.

One particular talk subject that might be of interest to some folks reading this blog is Daisuke Murase (aka typester)'s talk about UV.pm, a binding for libuv. I know several folks were asking me to prod him to release the module to CPAN. Well, apparently it's already up! :) Kudos to YAPC-driven development.

Day 1

It's Day 1! The real deal begins! This year we invited Larry, Tim Bunce, and Adam Kennedy, and as special guest, Ingy.

As the organizer I must confess that I missed all but a few of the talks, and can't quite tell you much about the content, but from what I could see, the operation went very smoothly. It was quite clear that having all the talks in the same building was A Good Thing -- in our previous venue, you had to move from building to building, which was a major constraint.

Aside from the main talks, this year we asked the folks at Hachioji.pm to host this thing called an "LT-thon (i.e. Lightning Talk Marathon), which apparently went very well. So folks just jumped in, one after the other, to talk about just about anything, in a relaxed LT-style during two days. You can check out their photos here

This min-event seemed to work out very well for people who were either too shy to register to the main LT sessions, or those who couldn't get into the rooms or were otherwise wandering the halls until their talk of choice started. A lot of people claimed it was a very good event on their blogs after YAPC.

Lightning Talks Day 1

Lightning Talks are one of the major reasons people come to our YAPC. We had a total of 30 or so speakers. I'm particularly proud that we had a non-techie lady doing a very entertaining talk. I pride that we allow room for newbies and non-perl-gurus to take the stage and make something interesting out of Perl.

This year we also decided to give away T-shirts for LT speakers. Dinosaur with a gong, baby.

Social / Free Dinner

As I said earlier, the dinner was FANTASTIC... or I've heard, since I didn't have a bite :/ See we had way more people coming in than we expected, so I at least tried to help the situation. Of course, it wasn't much when you have THIS many people. But I'm glad that of those that got to the food, they seemed very pleased.

Day 2

While I live in Tokyo, it's kind of a tiring ride to the venue from my apartment to the venue, especially when you have to be there at 8:00 am or 9:00 am, only after spending the entire previous day running around organizing the event (even more so because I have a new born baby), so I stayed at a nearby hotel.

I was so expecting the typhoon to hit us, but we managed to dodge it again, and in fact we had a very very sunny delightful day for the last day of YAPC::Asia Tokyo 2012.

So here goes Day 2!

During the morning, one of the talks that I was personally pleased to have was Mr. Kondo's talk / master course about Perl's context (scalar, list) and references. We were in desperate need for newbie material but not too many people are qualified / motivated enough like Mr. Kondo, who is the translator for "Learning Perl". It was a pleasure to have him, and I hope that these kind of "basic" material keep on showing up at the future YAPCs.

Lunch Match-up

As you may know, Japanese people are very shy. It's kind of hard to have 800 random people to come to the venue and immediately be able to kick off a conversation with somebody standing near you. So this year we had this thing to match up people and send them off to lunch. We even pay for the meal!

This is how it worked: During the morning, you get a raffle (-ish) ticket from this lady over here. At the beginning of lunch time, everybody gathers at the reception area, and we chose random tickets to form 5 groups of four people. They could go anywhere: just fill in and bring back a very simple questionnaire, and upon receipt, we just pay each person 1000 JPY for the lunch. The questionnaire had simple questions to introduce themselves, so they could easily start up the conversation. We haven't compiled the results / feedback yet, but based on the number of people who showed up, I believe this was worth doing as well.

The first event after lunch was the panel discussion with Miyagawa, Atsushi Kobayashi (aka nekokak), Tokuhiro Matsuno (aka tokuhirom), and Naoya Ito. They are all very famous Japanese hackers, and they talked about some history of Perl/YAPC/tech with Mr. Fuon who moderated the talk.

This was done in part because we have seen many new comers to YAPC in the recent years who may not know the context in which YAPC and Perl have been evolving.

Lightning Talks Day2

I had to make many improptu change of schedule for both Lightning Talk slots, but I believe I chose and ordered them well. Of those, I suggest you look at "Everybody Loves Suspenders", and "Perl 1 + 1 Stress Test", which I think are very interesting to see even if you don't speak Japanese (once videos are uploaded, I will link them here)

Heading towards the end

I'm generally of the opinion that techies MUST learn enough English to at least listen to talks, but the closing talk for YAPC::Asia Tokyo is a bit of special case. Throughout our history, we had "spiritual talks" (not as in religion, but as in motivational and stuff) at this slot, and while code speaks for itself, these sort of talks are much harder for non-natives.

So the previous three YAPCs we've purposely selected highly regarded persons to finish off the show. This year it was Gosuke Miyashita (aka mizzy), with his talk about how Perl changed his life, complete with a chance to publicly tell Larry "thank you" :)

Best Talk Awards

I gave my closing talk, very briefly. I know people were already tired, and they wanted to go grab something to eat and drink. We had the Best Talk Awards again this year, which is a chance to win some cool prizes, based on the attendees' votes. The goal of this is not only to say "thanks" to the speakers who spend so much effort putting good talks, but also to give something that will help them learn and write more code :)

Tatsuro Hisamori got the third place prize: A whole bunch of tech books that were on display during YAPC. Hopefully he will be able to put them to good use.

Second place as, Miyagawa. I don't know how/if he's going to manage it, but his prize is three trips within Japan to attend local pm meetups. Even though he now lives in San Francisco, I'm sure he will find time to go to these places :)

Yusuke Wada, got the first prize for Best Talk Awards. He is famous for running many cool services. The prize was to send him to either YAPC::EU or YAPC::NA next year, so expect to see this guy next year at your nearby YAPC!

Closing

So that was that. Now it was time to end the show. This year I tried to lay out what I'd like YAPC::Asias in the future to look like.

I want it to be open, welcoming. I don't want make it a place where only Perl's old boys group up and talk about the Perl world as they know. I want it to be a place where people who (loosely) share the Perl philosophy to talk about tech and exchange the latest and coolest ideas. I want people from other communities to come in: maybe share how cool their tech is, and show us what we're missing, or the other way around and talk about features or ideas that they would like to steal from Perl.

I want to share the greatness that this community I love has to offer, and I want it to keep on growing, evolving, and becoming better as time goes by. YAPC should be that kind of place.

And finally, we had 43 great people to help run the show. They are not paid (except we buy them lunch and host an after party), so they are there just to bring this great show for you. Thank you guys, you rock.

Oh and of course, thanks for my partner in crime, Kushii-san. Without him, there would be no YAPC::Asia Tokyo since 3 years ago :)

Meanwhile, I think this shows the importance for us event organizers to take professional photographs. This is the kind of place you want to use them pictures! They are well worth the $$ you pay. I suggest you definitely look into hiring someone for your next Perl event!

YAPC::Asia Tokyo 2012 is on Sep 27, 28, and 29! Tickets will be available soon!

However, there are myriad of people out there who don't know what it is. Especially people who are new. Since our company also hosts meetups and conferences on other topics, we thought it would be grrrreat marketing to let people know that we have a superb conference going on.

And so here it is: our new shiny leaflets for YAPC::Asia!

It says in the middle: "YAPC::Asia Is a Perl 'Festival'!". It explains a bit about what YAPC is, and on the backside there's a bit about what kind of people come to the conference -- especially, that you don't need to be a pro/expert Perl hacker. We have lots of interesting material even if you don't speak our lingua franca.

Oh, and we're still looking for YAPC::Asia Tokyo 2012 sponsors!

We accept sponsorships in increments of 50,000JPY. For our sponsors, we offer to publicize your logo on our pamphlets, and on our site, as well as a dedicated entry for you under our site (example).

If you have swag to give away, we are happy to distribute them at the venue, along with any advertising material (pamphlets or the like). If you are sending someone over to promote, we are happy to arrange something. Please contact us for details at info-at-perlassociation.org.

We hope to see you at the world's largest YAPC!