lestrrat

Recently I put up some apps for YAPC::Asia 2011 online. <plug>Yes, YAPC::Asia Tokyo 2011 is happening, and it's on Oct 13-15. Tickets will go on sale sometime mid-August. Call for papers is now open, please submit your talks!</plug>

Then I tweeted:

This years #yapcasia system backend will all be on #dotcloud. Thank you for a great infrastructure!

Then I got this following conversation with @rblackwe:

rblackwe: @lestrrat are you running Act on dotcloud?

lestrrat: @rblackwe nope. bunch of small custom psgi apps.

rblackwe: @lestrrat you hade me excited and hopeful.

... which is, well, understandable. By coincidence, I'd just had a conversation on IRC #act about this very fact on irc with Maddingue. I was being asked if we were using Act or not, and if not, why.

The short answer was: No, we haven't been using act since YAPC::Asia 2010, and the reason for that was 1) latency, and 2) admin burden.

So what happend was on 2009, I operated YAPC::Asia for the first time, and I inherited the website system from miyagawa.

While Act in itself is a great system, what I quickly found out was, well, the site is just literally too far away from Japan. You could see the page slooooooowly coming up your browser. That was a bummer, but but we could live with it. I don't know, maybe put a proxy in Japan, and handle the client connections there, while caching anything that we could to make the response faster.

The next thing that quickly started to annoy me was the fact that I need to go through Act admins to tweak settings. You had to go through email / IRC, talk to them and have them do root stuff to get some stuff done. This obviously took more time than I would've liked, and made me feel frustrated. I don't blame the Act folks for this, but it was just annoying to have to go through another layer of people to get some customization done.

On top of this, we wanted to radically change how check-ins were done at YAPC. Previously we were just printing out people's names and crossing them out from the list to figure out who came. Well, we're in the twenty-first century, baby. And we have 500+ people coming in. This is just too much work.

So in 2009, we brought some barcode readers ($500 a pop, but it was well worth it!). Attendees were expected to bring their "e-ticket" -- basically, we generated QR code png for every attendee, and all you have to do is to bring a printed copy or a device that can display the code so our barcode readers will be able to read it. This proved to be an extremely valuable tool, and we almost completely eradicated the long line of people waiting at the checkin.

However, there was a problem: It would have been very cool if we could get a hold of the entire attendee list from Act, but I didn't have a DSN to connect to. And thinking about it, if you allowed somebody like me to just randomly connect to the Act database, it would be somewhat of a security problem (you don't me to be peeking on your records, right?) so I decided not to ask for this, and went to the other route, which is to get the receipts from paypal transactions and create a database of expected attendees.

So we kinda worked around that problem, and ran YAPC::Asia 2009 with Act.

For YAPC::Asia 2010, however, there was now new problem: Namely, the company I was running was going down, and I was going to have to hand the organizer cap to somebody else. So we brought in Kushii (@941)-san to do the job, but he doesn't speak English, nor is he a techie. How on earth was he going to run Act?

Well, the answer was simple, because by 2010 the landscape for Perl webapps had changed: PSGI. Now that we had Plack and PSGI, it was now extremely easy to create small, custom apps, so we did.

For YAPC::Asia 2010, with the help of @yusukebe, we created small PSGI apps for 1) ticketing, 2) check-in, and 3) talk voting (we handled talk submissions via Google Docs, but regret that we did). These were just small daemons that did their job, and it worked out great. Now we had 1 DB with which we could do anything, on a server located in Japan that we could manage ourselves.

And so continuing onto YAPC::Asia 2011, we now have apps for 1) ticketing 2) talk submission 3) talk voting, and 4) check-in. They are all hosted on a dotcloud, and we have a proxy in Japan to make the responses quicker.

So what does this mean? That we hated Act? no, not really. It's just that we had issues that needed to be solved, and it was just easier to handle it ourselves. We are glad that these days we have bunch of tools to solve these issues.

Since talking to Maddingue on IRC, I've learned that Act is now on github for easier maintenance / development. I also learned that at least somebody wants to make Act act more like a distributed service, with RPC calls and such. That's great news, and maybe YAPC::Asia will go back to using Act then. Hey, I really can't argue that Act is more thoroughly engineered. After all, we hacked these PSGI apps in about 2~3 weeks. I'd like to use a better tested system, too!

Anyway, this article is not meant to incite wars or anything. It's just here to show why YAPC::Asia is not using Act, and how we are instead handling it. Hope this sheds some light on the whole thing.

Again, we're accepting talks for YAPC::Asia 2011! (if you're wondering about hotels, see also: this tweet from me). If you happen to want to promote your service to Japanese perl hackers, please contact me on twitter/IRC for sponsoring details!

Hope to meeting you guys at YAPC::Asia!