lestrrattag:blogs.perl.org,2009-11-03:/users/lestrrat//4322013-10-03T06:16:44ZA blog about the Perl programming languageMovable Type Pro 4.38A Lookback of YAPC::Asia Tokyo 2013tag:blogs.perl.org,2013:/users/lestrrat//432.51852013-09-28T02:03:16Z2013-10-03T06:16:44ZHere's a brief look-back of YAPC::Asia Tokyo 2013 using the official photo set, hosted by 30 Days Album. All the talk slides (at least the ones that the speakers uploaded) are available on our site, along with videos from each...lestrrathttp://mt.endeworks.jp
Here's a brief look-back of YAPC::Asia Tokyo 2013 using the official photo set, hosted by 30 Days Album. All the talk slides (at least the ones that the speakers uploaded) are available on our site, along with videos from each talk. The videos can also be checked out from our Youtube page

Day 0

Day 0 has always been the day where we, the staff, get our materials (swags, random equipments) together and do the initial preparation. Also, we host some smaller event during this time so that we can check our check-in process. This year we had a LTthon::Tiny (which stands for Lightning Talk-a-thon, where people just continuously keep presenting lightning talks after another), hosted by Hachioji.pm.

This year we completely underestimated how many people were going to show up to this pre-YAPC event. To be honest, our check-in operation failed miserably. Of course, this is why we do day 0: to test our operation, and to get our volunteer staff familiar with the process.

While we're struggling the overwhelming number of attendees, LTthon got started. Of course, we provide some beer, refreshments, and snacks.

One of the slogans that we started was "YAPC ain't over until you blog about it". This year one of our sponsors (who runs a blogging platform), used it in one of their in-venue ads.

2.5 hours of Lightning Talks. Ain't it great?

Apparently there was a "Best Lightning Talker" award, courtesy of Hachioji.pm

Day 1

Day 1 got rolling, starting with my partner in crime Kushii (aka 941)-san doing the opening talk, immediately followed by Ricard Signes' talk on current state and future of Perl5.

This year's Main Hall has a capacity of about 500, even equipped with a second-floor seating. Ricardo looks so alone on the stage :)

For this year's YAPC::Asia, we decided the theme of the event to be "お祭り" = (Japanese Traditional Style) Festival. So we made decorations as such.

Some sponsors also got an お祭り-style booth.

Not only did big companies helped us financially. Some individual attendees bought our +$50 tickets to aid us, so we made them extra cool T-shirts and these lanterns with their names on it.

BTW YAPC::Asia Tokyo 2013 fell right on the time for Harvest Moon. In parts of Asia, this time is celebrated according to local customs: In Japan we make these little sweets made with rice, and enjoy the beautiful moon.

If we just placed the sweets and the flower it looked kind of sad, so we got a real calligrapher to write these pieces. Yes, we got all this stuff just for YAPC :) The left one says "Ruby, Python, And Languages All Shall Be Friends", the center one says "Place Your Soul In Thy One-Liner", and the right one says "Pearls (Perl) Shall Fill The Sky and Hackers Shall Do The World As The Please".

We also had drawings for lunch meetups. We basically have attendees draw tickets and match them up and send them to lunch, so even if you came to YAPC w/o knowing anybody, you still got to socialize (forcefully) with others. If you were lucky, you also got one of our free bento lunches.

All while this is happening, talks for Day 1 are going on... This year we had a total of 70 talks on 4 tracks, including a hands-on session for Perl beginners.

During lunch time on both Day 1 and Day 2, we had a sponsored session where some of our sponsors got to present who they were, and what kind of cool stuff they were doing. Hey, we even got Microsoft to come talk!

Meanwhile people who drew the lunch meetup tickets were being called. I had to order a total of approx 400 bento boxes for this event. Phew!

And the show goes on. Speakers this year got a $10 (about 3 cups of coffee) worth of Tully's Coffee prepaid card, by the way.

Then it's time for ... Lightning Talks Day 1! Yes, YAPC::Asia Lightning Talks are notorious for their quality. The Main Hall was packed!

This guy did (pretty much) a stand-up comedy talk in 5 minutes. It had NOTHING to do with Perl, but boy, it was wicked...

The author(s) of JSX were also present in the Lightning Talks. Also one of the speakers did a presentation in Chinese. For the first time, I knew exactly what it feels like to go to a foreign conference and not understand a word being said.

Social / Free Dinner

This year the venue had this restaurant / ceremony hall called Queen Alice in the same building. We were so lucky to have this place for us. We packed 300 people for the dinner, but the food/beverage was never-ending. This is probably the first time where I was able to talk in a caterer to provide us with enough food/beverage so that it lasted until the social was over. Yes, YAPC attendees eat like a starving teenager.

Day 2

On Day 2 the check-in was much more relaxed. about 90% of the 1131 attendees had already registered by this point.

Day 2 is also full of talks!

During the afternoon, we had panel discussion session title "Tell Us What's Great About Ruby" ("And We Will Steal It" is implied :). I think it was a great session that showed many people where these two technologies are similar and/or different. Many people seemed to appreciate the session, as it was voted 3rd place in the Best Talk Awards later. Many thanks to the panelists and the moderator.

Again, the talks go on...

During Day 2, we asked the people at Perl Entrance to host a special one day workshop/hands-on for Perl beginners. Perl Entrance is a great program which takes people through learning Perl during a 6 month semi-regular schedule. One of the really attractive things for this project is that many well-known/expert Perl programmers come and provide guidance to the newbies. I hope to see this program grow over the coming years.

And again, it was Lightning Talks Day 2!. I dunno, but there's always a lady who wants to be the "gong girl". The one on the left did Day 1, and the one of the right did Day 2. Un?fortunately, I can only remember 1 or 2 people who actually had to be stopped by the gong, so I think they didn't have much work to do. Yes, Japanese people are so punctual that even their Lightning Talks are on time...

Since so many people wanted to give Lightning Talks, I crammed in 15 talks in 1 hour. so I asked them to shorten their talks to a 3 minutes, if possible. Yes, I'm the organizer. I'm an evil organizer.

I always put Takesako-san as the last guy, cause he always have something wicked and/or funny to show. This year he did an all-hands quiz for the audience to answer, with questions like "Can Perl handle identifiers as long as 255 chars? Yes/No?". The person standing until the last question got a prize (a book he wrote)

The last keynote was from Ikebe-san, talking about engineers and management.

Then it was my turn for the closing talk. As I've already said, we had 1131 attendees this year. We raised approximately 12 million yen for this event, and it took us about 9 months of preparation. It was a long way, but in the end it wasn't as hard as it sounded because of the help from our sponsors, staff, and others.

The Best Talk Awards are given to people who got the most votes during the conference (we have a little app for attendees to cast votes to). 3rd place was Masahiro Nagano (aka kazeburo), 2nd place was Tatsuro Hisamori (aka myfinder), and the first place winner was Yusuke Wada (aka yusukebe). The winners of the first and second place were actually the same as last year. Impressive.

Then I announced that this will be the last YAPC::Asia Tokyo, at least for Kushii-san and myself. The venue went kind of silent, but unfortunately that's the way it had to be. I'm pretty sure somebody will pick up where I left off, and maybe in a few years, when my son gets old enough I can go back to helping whoever doing the even then.

Finally, our staff. This year was interesting because we built a custom network just for this event. Upon hearing about the venue's built-in network, (even with my half-baked knowledge about network) I immediately realized that it wasn't going to be able to sustain hundreds of engineers working the Wi-Fi to its limits, so I asked people from JANOG and LLNOC to help us. They contracted the local network provider, got help for the upstream network, and built a custom Wi-Fi network for the entire venue. It was very stable, and it even survived half the audience downloading iOS7 at the venue (the new iPhones/iOS came out on that day...)! Kudos to them, I'm so glad I met these people.

And our volunteer staff. This event wouldn't have been possible without them.

So that was it. The staff spent the next hour packing, and our YAPC was over.

I was involved in the first YAPC::Asia Tokyo 2006 as staff, and have been involved in all of the YAPC::Asia Tokyo's since then. The last 5 years, I was the organizer. During the last 4 years, I had the help of Kushii-san, who became the mastermind of what goes on, so I could focus on financial stuff, speaker relations, and legal stuff. Organizing YAPC::Asia Tokyo was one of the hardest assignments in my life, but it was also one of the most fun. I had a really great ride during the last 8 years. Thank you for all those who have helped, visited, and otherwise supported our event. I'm sure I'll miss it in the near future, but for the moment I'm moving on. See you at YOUR next YAPC.

]]>
YAPC::Asia Tokyo 2013: Fighting Legacy Codetag:blogs.perl.org,2013:/users/lestrrat//432.51602013-09-24T12:10:02Z2013-09-26T00:24:37ZDue to popular demand, I'm going to post a summary/transcript of my presentation for YAPC::Asia Tokyo 2013, titled "Fighting Legacy Code". It's also the presentation that I would've given if I didn't cancel my attendance for YAPC::NA Austin 2013. Because...lestrrathttp://mt.endeworks.jp
Due to popular demand, I'm going to post a summary/transcript of my presentation for YAPC::Asia Tokyo 2013, titled "Fighting Legacy Code". It's also the presentation that I would've given if I didn't cancel my attendance for YAPC::NA Austin 2013.

Because I wrote all this in a rush, the language is very terse. Please let me know on twitter (@lestrrat) if somethings don't make sense.

You could also take a look at my Japanese slides while reading through this. You may get a little more feel for what I'm writing about.

]]>
Fighting Legacy Code

This is the story of an engineer who started working on the codebase for livedoorBlog, Japan's largest blog service, serving billions of requests every day.

livedoorBlog

Some facts:

Started 2003 (10 yrs in service!)

Very featureful

Many, many engineers have worked on, and have moved on from this codebase

Approx 220,000 lines of Perl code

Everything glued to mod_perl 1.3.x and perl-5.8.8

Pageviews / Unique user counts are not publicized, but I can confirm that it actually handles a pretty scary amount of requests. The content served is dynamic (no static html generated), and we utilize caches in various formats to make it all work fast. I can also confirm that the backend app servers handles about 1 billion raw requests per day.
The whole system consists of a few hundred servers (low hundreds)

The goal of my assignment is to make this 10year-old mess of a codebase easier to develop, easier to operate, more modern. This presentation takes you through stuff I worked through during the last 9months or so.

So what did I do?

Well, so first things first: THERE. IS. NO. SILVER. BULLET.

There's no magic middleware that makes all the problem go away. There's no One True Way To Refactor that gets you all the modern stuff in. There's no buzzword that will solve all your problems.

Instead, this is what you do: You patiently write, refactor, move around, remove code -- one by one, in small steps. The only way to make this work is to work hard at it.

Back to our target

So more details about our system:

perl-5.8.8

Glued to mod_perl 1.3.x.

Makefile.PL doesn't exist. Dependencies are kept in *.tar.gz files

Dependencies are old. Versions from 6~8 years ago

There are bunch of code you don't know what they do, and code that isn't even being used for the last few years

In other words, it's your stereotypical legacy system.

Until up to this point, the engineers and staff were making this system work through sheer power of will and brute force application of technology. Note: in this talk I will stress on the bad aspects but when you start looking at the code you start realizing that this system is indeed well thought out. it's just... old.

Anyway, from now on we need to cleanup the implementation of this system and make it easier to do new things in the future.

Low-Level Goals

Upgrade perl, and make it possible to keep upgrading perl in the future

Modernize the packaging of the system

Say farewell to mod_perl

Automate bootstrapping to make it easier for newbies (like myself!) to start working on the codebase

And remove anything else that might otherwise become obstacle to development and operation in the future

Perl Upgrade

Of course, I really wanted to upgrade Perl asap, but ... our code was running on mod_perl 1.3.x built against perl-5.8.8. We'd have to switch to PSGI before we could change perl versions.

Ugh. Commented out warns are not logs. They are just doodles in our source code.

We need our logs to be

All over the place: preferably in every important conditional blocks

Informational: Don't just print out "x = 1". Print "X = 1, so XXX needs to happen next" or some such, so that you can figure out what's actually going on

Easily toggle-able: Commenting out logs is a sure way to fail. We need to make all logs appear/disappear with just a flip of a switch.

So for our purposes, we use Log::Minimal. We could have put a more flexible OO-ish loggers, but for our purposes, we want to put logs all over the place, without any effort. Log::Minimal provides a functional interface that can just be inserted anywhere, so this is good.

Also, we don't want to slow down production code just because of our logs. For that you should use constant folding:

Then I started fiddling with the class hierarchy for the Apache handlers. I moved all the switches to the parent class, and made them class-based switches (via Class::Data::Inheritable), so it would be easier for me to convert these into objects later.

Then I released the converted version. This contained new logging mechanism, the class hierarchy, etc.

Then immediately I got hit by a bug: All of our 404 pages (served via ErrorDocument directive) turned white. nothing.

Turns out it's because mod_perl 1.3.x has this odd rule to enable ErrorDocuments. You want to return 404, and show an ErrorDocument: can you guess which combination works?:

$r->status(404), return Apache::OK

$r->status(404), return Apache::NOT_FOUND

$r->status(200), return Apache::OK

$r->status(200), return Apache::NOT_FOUND

$r->status(404), $r->send_http_header, return Apache::OK

$r->status(404), $r->send_http_header, return Apache::NOT_FOUND

$r->status(200), $r->send_http_header, return Apache::OK

$r->status(200), $r->send_http_header, return Apache::NOT_FOUND

Answer: $r->status(200), return Apache::NOT_FOUND. Seriously, how are you supposed to get this.... mod_perl must die.

Stuff like this kept popping up. My hatred against mod_perl grew every day, but nonetheless...

Phase 2: Migrate the Distributor to PSGI

So finally we had a cleaner set of Apache handlers. It's time to make'em PSGI.

First all the handlers were turned into Plain Old Perl Objects, and I swapped all the Apache::Request usage to Plack::Requst. Then, fix, try, find an error, fix, try... repeat.

On the way, I wrote Geest, which is a port of Kage to Perl/AnyEvent. This allowed me to send requests to both the development app and the production app and compare if my implementation was different the production one. Turned out to be a great tool while I was still learning how the whole system worked. We don't use it anymore, but it's a cool tool to have during selected parts of the development cycle.

Once I started converting stuff to PSGI, I started using a bunch of really useful middlewares, and other assorted tools:

And then THIS was the right time to upgrade perl. I upgraded from perl-5.8.8 to perl-5.16.3, making a 7-year leap. Meanwhile, if we are going to modernize we might as well use cpanfile and Carton. So we did.

At the time, we used cpanfile >= 1.6, with explicit versions requirements ("requires DBI => '==1.628'"), and Carton 0.9. The prereq modules are in a list so I started manually bringing them in, one by one. Install it, run the software, see if it failed, repeat, repeat, repeat.

There were also some modules that were not up on CPAN: in-house modules. I had the tarballs. I wanted to just install them via cpanm/cpanfile, but there was this install order problem (e.g., we needed Class::Trigger 0.09 -- if I just put it in cpanfile, the chances were that some other module which depends on Class::Trigger might install the latest one instead). So I scripted this part so that all the correct versions were installed.

Then it hit me: it's not just the prereqs. My coworkers will have to do the whole setup on their boxes again. yikes! Nobody's going to adopt my software!

So I made it so that my PSGI app script did ALL the required initialization, creating dirs, installing the right mysql binaries, even applying patches on modules that needed to be installed. All that my co-workers needed to do was to enable this PSGI app script, and it would do the rest. This way they couldn't complain.

Having done all that, it was time to DEPLOY!

.... Of course, all hell broke loose: performance was down by 30%. Not a good thing when you have billions of hits.

Our resources are recorded via CloudForecast so first I tried tweaking the number of workers while checking CloudForecast graphs. Well, turns out it wasn't a good idea. The load average went up, and we started getting many alerts. It was now time to closely review the source code.

My coworker (kazeburo) was profiling away our app using Devel::NYTProf. He actually found a lot of things there.

One thing he found out was that, because I was using a lot of mount() calls, I was wasting some precious resource. I changed all those to simple hash lookups, and we were now handling twice as much requests. See https://gist.github.com/kazeburo/5087266.

Also, Plack < 1.0018 had a little problem. Namely, query_parameters() was a bit inefficient. It was calling uri() twice, and it wasn't even caching it. We moneky-patched it and the performance improved by 10~15%. It's fixed in Plack >= 1.0018.

While we were at it, we thought it might be better to micro-optimize this hot-path (we were using a LOT of query parameters). So I started writing Text::QueryString, then I was quickly informed of URL::Encode::XS by its author. Turns out URL::Encode::XS was faster AND more correct, so we started using that. We again monkey-patched Plack::Request and we squeezed another 5 to 10%.

So turns out that at least compared to Plack > 1.0018, Apache was a pretty darn efficient guy. It was faster doing HTTP request parsing and stuff. But memories always seem better then they actually were. It was time to say good by to mod_perl regardless...

Now we could finally deploy and be happy. Yes!
Except, until we tried hot-deploying a minor fix by sending HUP to Server::Starter.

If you are on a busy box, and you try to replace generations of apps like Server::Starter does, you need to realize that by default it will bring up the workers with the new generation code and then kill all of the old workers ALL AT ONCE. That means the load average goes up momentarily, and you might have brief service interruptions. This is clearly a FAIL.

By setting signal-on-hup on start_server, and using spawn-interval for Starlet, you can achieve "slow restarts". Basically a new generation worker comes up, but the next one only comes up after the specified seconds in spawn-interval. The same goes for the killing of old workers: one old worker is killed, only after the specified interval is the next one killed.

So you get to see the processes gradually being replaced. Watching this via "watch 'ps -ef | grep plackup'" is kind of fun.

And now we can finally properly hot-deploy new code... (actually there's a bit more to do, but we'll touch that later)

Phase 3: Migrating Sledge

Now the other Sledge based components. Sledge is, as I previously described, a really old web application framework. I personally hadn't touched it since 2005.

To port this to PSGI (Sledge is natively mod_perl based), we needed a Sledge adapter. There is a Sledge::PSGI module, but I heard that it's not the most efficient adapter through the grapevine (apparently copying the entire contents of PSGI $env to %ENV for every request adds up). We need to squeeze out every last bit for this application, so I built a custom Sledge PSGI handler.

Sledge was natively mod_perl based. It expects Apache::Request everywhere. And the way Apache::Request was being used was way more extensive than Phase 2. I didn't want to change all the Apache::Request - Plack::Request incompatibilities by hand.

Answer: Create a facade that is Plack::Request based, but acts like Apache::Request. I saw some modules like it on CPAN, but they weren't exactly what I was looking for... so I wrote my own FakeApacheReq object. The good part was that because I have completely control, I was able to embed warnings when certain wicked mod_perl-isms were being used. One notable gripe of mine was the upload() method and the weird interaction with param(). See the slides for this.

Also, the problem I encountered with Sledge-based code was the liberal use of %ENV.

Oh god, no. %ENV is a GLOBAL! WHY ARE YOU.... Ugh, nevermind. How am I going to escape this one... In the end I decided to track down all the occurrences of this pattern, and replaced them with an equivalent of

local $ENV{ .. } = $r->header(...);

I wasn't going to set %ENV, because for one it's exactly what we wanted to avoid when we decided not to use Sledge::PSGI, and two, I was not going to allow my co-workers to EVER use this global again in their code. %ENV usage like this had to go.

As far as Sledge was concerned, this was about it. It turned out that when you have a set of well defined API between your environment (mod_perl/PSGI) and your app, migration is much easier.

Phase 4. Going Further

So then most of the code was finally ported to PSGI. It was now time to make some fine adjustments so that things were even easier.

One problem I found was that when you wanted to fine-tune the number of workers/max-requests-per-child/etc on Starlet, you needed to send a TERM signal to the start_server program. This is because start_server takes the arguments it was given the first time it was fired up and keep reusing that to spawn new generations.

Therefore in below code, everything after --signal-on-hup... is reused every time you tried to hot-deploy the code

This code is a wrapper that loads the Starlet server via Plack::Loader, the PSGI app, and sets all the required parameters. start_server only sees bin/jp2_app, so if you change its contents to pass a different parameter to Starlet, the new settings are honored.

The next minor problem/annoyance was the fact that we had too many plack processes. app A, B, C, might be running on the same box, and since stuff like "ps | grep plackup" gave me all the apps' processes, it was really annoying to look for that one process that we wanted.

Fighting legacy code definitely doesn't stop here. There are more stuff that I want to do, like more fine-grained clustering, more automated tests, fixing up the job queue mechanism, normalizing databases (imagine a 10 year old database... it's hell!), upgrade (!) our mysql4 servers to mysql5, use DTrace instead of debug logs...

There are plenty of things to do. Maybe next time I get to talk about all this.

]]>
YAPC::Asia Tokyo 2013 is overtag:blogs.perl.org,2013:/users/lestrrat//432.51532013-09-21T14:17:03Z2013-09-21T14:27:05ZSo I just came back from the staff after party. I'm exhausted. So I'll only write the important stuff: This year, we had 1,131 attendees (ticket sales, invited guests, speakers, staff) I'm pretty sure this is THE BIGGEST YAPC EVAH...lestrrathttp://mt.endeworks.jp
So I just came back from the staff after party. I'm exhausted. So I'll only write the important stuff:

We provided Wi-Fi to all the attendees via custom built network, and we saturated a 100Mbps line when our attendees started downloading iOS7 simultaneously

This is the LAST YAPC::Asia Tokyo that 941-san, and myself will do. There are no plans to host another YAPC::Asia Tokyo next year, unless someone steps up to take up the challenge.

I was involved in all of the 8 YAPC::Asia Tokyo's previously held. I had a wonderful ride. It was pleasure, but it's time to move on

Videos, photo footage, and blogs will be posted soon-ish. Stay tuned.

]]>
PerlMotion - Perl For iOStag:blogs.perl.org,2013:/users/lestrrat//432.50912013-09-06T10:41:31Z2013-09-06T10:51:59ZWhile it's still just started, goccy, a Japanese hacker who has been working on rather cool modules, has been working on PerlMotion, which allows you to write iOS apps in Perl. I'm not an iOS guy so I haven't delved...lestrrathttp://mt.endeworks.jp
While it's still just started, goccy, a Japanese hacker who has been working on rathercoolmodules, has been working on PerlMotion, which allows you to write iOS apps in Perl.

I'm not an iOS guy so I haven't delved too deep into it, but other than the fact that it could use a bit more packaging love, I head that something is actually running on iOS... Although I'm not involved in project, I personally would love to see it get input from a lot more people, so I thought I'd let you guys know.

]]>
Visualizing YAPC::Asia with HRForecasttag:blogs.perl.org,2013:/users/lestrrat//432.47322013-05-31T05:47:58Z2013-05-31T05:56:27ZThis year we're using HRForecast to keep track of ticket sales and talk submissions for YAPC::Asia Tokyo 2013, and it's looking good. I highly recommend you using these tools to visualize your data...lestrrathttp://mt.endeworks.jp
This year we're using HRForecast to keep track of ticket sales and talk submissions for YAPC::Asia Tokyo 2013, and it's looking good. I highly recommend you using these tools to visualize your data
]]>
My colleague @kazeburo is an extremely talented operations engineer. One of the things he stands by (note: I don't I think I ever heard him say these words to my face, but I believe from his actions and his products that this is what he thinks is important) is that to really grok what's going on in your system, you need to visualize your data.

GrowthForecast is sort of a generalization of CloudForecast -- it doesn't define what metrics it's recording but instead allows you to visualize any real-time data such as: number of HTTP requests per second, number of items in a queue at the moment, etc. Because this graph can be generated via HTTP API calls, all you need to do is to setup GrowthForecast, and a cron job or something that periodically makes HTTP POST request, and you get a nice looking graph.

Below is a sample of GrowthForecast graph, which shows the number of items in an STF queue (which is an Amazon S3-like distributed storage). This is generated by simply doing a "SELECT COUNT(*)..." and then calling LWP to POST to GrowthForecast. Easy, and yet extremely effective.

HRForecast is much like GrowthForecast in that you can create graphs by issuing HTTP requests, but the difference is that HRForecast is not restricted to real-time data so you can post a piece of data to graph AND time which this happened. It also aims to visualize data for a much longer span, typically weeks and years.

So that was a long setup, but here's where YAPC::Asia Tokyo 2013 comes in. Until last year we basically just manually checked our databases or looked up the web page for the company doing the ticket sales to get the number of registered talks and/or number of tickets sold, but this year I wanted to slack off more: I wanted to just look at a graph every morning, and know what our status was.

So we setup HRForecast!

Then I made a few cron jobs that counts the number of registered talks via "SELECT COUNT(*) ...", and another batch that fetches CSV files from the ticketing service, groups them by their ticket types, and counts the number of tickets. All of these then just makes HTTP requests to HRForecast, and we're done.

The result looks like below. Now all I do is to check these graphs every morning, and I can immediately see the status of our conference. Neato!

]]>
Call For Papers Open (YAPC::Asia Tokyo 2013)tag:blogs.perl.org,2013:/users/lestrrat//432.47212013-05-27T08:38:01Z2013-05-27T08:44:41ZCall For Papers is now open for YAPC::Asia Tokyo 2013! 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...lestrrathttp://mt.endeworks.jp
Call For Papers is now open for YAPC::Asia Tokyo 2013!

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!

]]>
Perl5 Census Japan 2013tag:blogs.perl.org,2013:/users/lestrrat//432.46002013-04-23T05:38:38Z2013-05-08T03:42:37ZDuring Apr 7 - 19, I conducted a web questionnaire targeting Japanese Perl users, which I titled "Perl5 Census Japan 2013" ;) I purposely asked people spreading the news to specifically state that this was not just for hardcore Perl...lestrrathttp://mt.endeworks.jp
During Apr 7 - 19, I conducted a web questionnaire targeting Japanese Perl users, which I titled "Perl5 Census Japan 2013" ;)

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 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.

]]>
Q. Where do you live

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.

]]>
The Main Problem With CPAN Modules On Githubtag:blogs.perl.org,2013:/users/lestrrat//432.44052013-03-09T05:07:51Z2013-03-10T07:22:02Z....Or, this entry is better titled as "Use cpanfile, and make sure to add it to your repository" UPDATE: read miyagawa's comment (note, this linked comment has the summary, but make sure to read the others), and his blog post...lestrrathttp://mt.endeworks.jp
....Or, this entry is better titled as "Use cpanfile, and make sure to add it to your repository"

version range specification, including exact version match, not "at least version X"

The reason I say this is because when you do `cpanm $git_url` on modules without META.yml or cpanfile, your installation process barfs if you don't have the modules required to run Makefile.PL / Build.PL. For example, I see a lot of github issues claiming that modules using Module::Install (and its plugins) failed to install via github. This works if you're downloading the complete tarball from CPAN because then you presumably included all the files in inc/, but you usually don't include this directory in your repository.

With cpanfile, you can declare this dependency in the `on configure` section:

When this included, cpanm 1.6+ with "--installdeps" option will just pick it up and do the right thing.

Here I described a common problem with Module::Install, but this may happen if you use other pluggable mechanism. It also strikes me as odd that with perl the build process must be run to detect prerequisites for the build process... (what?! what am I saying?), thus I believe that prerequisites should be declared separately from the build process, and hence cpanfile.

Note: META.yml is fine, except you have zero dynamic configuration. cpanfile allows you to specify dependencies separately AND it can be dynamic.

So let's put cpanfile on all our repositories, and when you have dependencies on experimental stuff, why not just specify the repository url:

And as a final note: Yes, I am guilty of not including cpanfile in all of my modules, but I'm getting to it one by one. Please file an issue if you encounter problems.

Happy cpanfiling, everybody.

]]>
Testing Refactored Webapp Against Current Version With Geest (Ruby Kage port)tag:blogs.perl.org,2013:/users/lestrrat//432.43512013-02-19T02:39:36Z2013-02-19T03:20:26ZI'm currently working on a big, and I mean /BIG/ codebase, like 200K LOC with about 10 years of history behind it. In this post I'll briefly describe how I'm refactoring code using a little tool called Geest (github), which...lestrrathttp://mt.endeworks.jp
I'm currently working on a big, and I mean /BIG/ codebase, like 200K LOC with about 10 years of history behind it.

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.

]]>
I'm currently refactoring mod_perl (1.3, mind you) code into PSGI, however, being that there aren't many, uh any, tests, and a lot of code that depends on wonky mod_perl behavior and stuff, the way this refactoring proceeds is basically as follows:

Read the code

Write some code

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:

Staging is considered to be "master", which means that response from "staging" is preferred when replying to the client

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:

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.

]]>
Recent work on ZMQ::LibZMQ3 and CZMQtag:blogs.perl.org,2013:/users/lestrrat//432.41882013-01-10T07:32:50Z2013-01-10T07:44:43ZDuring the last leg of my new year's vacation, I started hacking on ZMQ::LibZMQ3 et al again, due to gentle prodding from @melo to include zmq_proxy(). What seemed like a simple API addition in the end turned into myself writing...lestrrathttp://mt.endeworks.jp
During the last leg of my new year's vacation, I started hacking on ZMQ::LibZMQ3 et al again, due to gentle prodding from @melo to include zmq_proxy().

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.

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!

]]>
A Glimpse of YAPC::Asia Tokyo 2012tag:blogs.perl.org,2012:/users/lestrrat//432.39082012-10-02T02:48:41Z2012-10-04T06:52:08ZSo, like my entry on YAPC::Asia Tokyo 2011 last year, I thought I'd give you guys a very brief tour of what it was like this year. Before I start, you can find the full set of photos here, and...lestrrathttp://mt.endeworks.jp
So, like my entry on YAPC::Asia Tokyo 2011 last year, I thought I'd give you guys a very brief tour of what it was like this year. Before I start, you can find the full set of photos here, and videos will be uploaded here.

]]>
For the last 3 years, we were lucky to have been able to use the same venue at Tokyo Institute of Technology, but for this year we were (again) lucky enough to be able to rent the fabulous Ito International Research Center in University of Tokyo, so we decided to change venues.

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.

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 :)

The official attendee count (based on ticket sales) was 743. If you added the speakers, it was 798, and if you added the staff, it was 841. At any given moment there were about 400 ~ 600 people in the venue. There were some no-shows too, but we haven't counted it. Thanks for all our attendees, our staff.

I'm honestly baffled by how big this event was. I seriously don't know if we can beat these numbers in the future. I'm tired. I want to see my son now (who has been with my grandparents and my wife since 3 nights ago).

We still got a few things to do, but YAPC::Asia Tokyo 2012 is over. We had a blast.

Hope everybody enjoyed it, too!

]]>
YAPC::Asia Tokyo 2012 Day 2tag:blogs.perl.org,2012:/users/lestrrat//432.38962012-09-28T23:08:59Z2012-09-28T23:26:53ZWhoa, it's already 9/29, which is Day 2 for YAPC::Asia Tokyo 2012. This year's YAPC is going extremely well. I don't know, as an organizer I'm finding myself not having to hassle much. Something tells me we've passed a glass...lestrrathttp://mt.endeworks.jp
Whoa, it's already 9/29, which is Day 2 for YAPC::Asia Tokyo 2012.

This year's YAPC is going extremely well. I don't know, as an organizer I'm finding myself not having to hassle much. Something tells me we've passed a glass ceiling of sorts: I think we've reached the point where our reputation and our brand recognition is enough for the event to take life on its own. The speakers roll the show. The hallway tracks bring up the excitement. The attendees are finding more ways to enjoy the show.

I'm just going from room to room where the speakers non-Japanese, translating questions/answers, taking care of extra, unforeseen costs, checking out on our guests from abroad, and organizing the lightning talks - which may sound like a lot, but compared to previous years that I have been involved in this event, is a lot less stressful stuff.

I think that with only the minimal effort, YAPC::Asia Tokyo (or wherever in Japan) will probably be able to stand on its own.

Miyagawa took the boat off in 2006. It was beautiful, but it was still a frail boat that could quite easily be lost if it found its way against some bad weather.

Kushii-san (my partner in crime and the mastermind behind the last 3 YAPC::Asia's) and I kept the spirit but practically tore that boat apart, rebuilt it, made it into a real ship that can sail across the stormy oceans while carrying hundreds of people in it in the last 4 years.

It's a great pleasure to see the vessel that we nurtured to take a life on its own.

Hopefully it will keep evolving. I don't know if it's going to be bigger, or any different. But I think it's ready to take on just about anything, with just the minimal required effort.

Anyway, 9 more hours of pure geeky-ness to go this year. I hope that any non-Japanese participants reading this entry have enjoyed Day 1, and that you also enjoy today's show even more.

]]>
YAPC::Asia Tokyo 2012 Day -1tag:blogs.perl.org,2012:/users/lestrrat//432.38842012-09-26T02:03:10Z2012-09-26T03:39:41ZYAPC::Asia Tokyo 2012 is almost upon us! Tomorrow, 9/27, is Day 0, where we will hear a few talks and have some snacks and socialize. Doors open at 17:30. Anyone with a ticket can attend this event. See the timetable...lestrrathttp://mt.endeworks.jpYAPC::Asia Tokyo 2012 is almost upon us!

Tomorrow, 9/27, is Day 0, where we will hear a few talks and have some snacks and socialize. Doors open at 17:30. Anyone with a ticket can attend this event. See the timetable here.

9/28 is Day 1. This is when YAPC::Asia Tokyo 2012 really starts! Doors open at 9:00, and goes all the way until 19:00. Free dinner is available starting at 19:00, at the area right next to the main hall. See the timetable here.

Oh, and some bad news. Apparently a tropic typhoon is on its way to hit Tokyo area right on 9/28. Bring your rainwear and/or keep checking the weather news!

If you have problems (especially with English/Japanese) please find me (@lestrrat)

]]>
YAPC::Asia Tokyo 2012 Best Walk Awards!tag:blogs.perl.org,2012:/users/lestrrat//432.33202012-06-01T06:02:09Z2012-06-01T06:14:14ZSince YAPC::Asia Tokyo 2010, we have been hosting voting on "Best Talk Award" for talks that go on YAPC::Asia Tokyo. We are also giving away prizes for the winners of these awards -- for 2010, we gave a Macbook Pro...lestrrathttp://mt.endeworks.jp
Since YAPC::Asia Tokyo 2010, we have been hosting voting on "Best Talk Award" for talks that go on YAPC::Asia Tokyo. We are also giving away prizes for the winners of these awards -- for 2010, we gave a Macbook Pro with all the bells and whistles, and last year we gave a dandy ergonomic chair.

This award was originally created in hopes that giving talks at YAPC::Asia Tokyo will also also be rewarding for the attendees, and also to give them some incentive to learn more, to do more. We believe that giving them a chance to attend these conferences will be an extremely cool opportunity to mingle with people who otherwise they may never meet in person, and to feel what it's like in other conferences.

Of course, we are assuming that a Japanese local would get the award, but if somebody living abroad gets this award, we'll try to arrange something. Do visit us if you're interested!