Masteries

技術的なことや仕事に関することを書いていきます.

僕達の日常に這い寄るGet Wild

この記事は, Get Wild Advent Calendar 2016の13日目の記事です.

はじめに

皆さんGet Wildしていますか? 最近はどっちかというとBE MY BABYしている機会が多いのですが, とりあえずチープなスリルに身を任せながらGet Wildしていきましょう.

日常に這い寄るGet Wild

さて, 勢いでGet Wild Advent Calendarに応募してしまい, どういったネタ記事を送り出すべきかと, ひとりでは解けない愛のパズルを抱きながら考えていました.

前日になってもアイデアが浮かばず, 明日におびえていた訳ですが, その最中私は気づいてしまいました.

...すでに私達の身の回りには, Get Wildが, 音もなく, 静かに這い寄ってきていたということに.

どういうことか?

例えば, ここにピックアップしたのは, 今自分が携わっている某サービスのインフラ〜ミドルウェアレイヤーで使われているツールの一覧です.

  • GitHub
  • AWS
    • EC2
    • ElastiCache (Redis)
    • ElasticSearch
    • RDS (MySQL)
    • S3
    • Route53
  • Linux (Ubuntu)
  • Terraform
  • Itamae
  • Packer
  • Concourse CI
    • Docker
  • Mackerel
  • WordPress

GitHubでリポジトリを管理して, AWS上にサービスを構築. AWSはTerraformで構築の自動化を試みています.

サービスはEC2上で動き, OSはLinux(といっても, Amazon LinuxではなくUbuntu)を採用しました. みんなだいすきInnoDBを使いたいので, RDSのMySQLを採用し, 必要に応じてRedisやElasticSearchも導入しています.

アプリケーションが動くインスタンスはAMIをPackerで構築してそこから起動しますが, 「踏み台サーバー」などのミュータブルなインスタンスについてはItamaeで構築します.

デプロイの自動化については, Concourse CIを採用しています. Concourse CIでは, 各ジョブがDockerのコンテナ上で動くので, CIサーバに直接デプロイなどに必要なミドルウェアやツールを導入する必要がなく, そういったツールが入ったDockerのイメージを作ってあげればOKなので, 非常にわかりやすいです.

また, インフラの監視にはMackerelを, 公式サイトのためにWordPressを使っています.

なるほどなるほど, 「GitHub」... 「EC2」... 「Terraform」... 「WordPress」... 「Itamae」... 「Linux」... 「Docker」... ハッ!?

G E T  W I L D

そう, 私達のサービスは, 知らないうちにGet Wildが紛れ込んでいたのです...!

あなたの側にもGet Wild

皆さんも, 改めて開発しているサービスに注目してみてください.

もしかすると, 皆さんのサービスも, 既に, Get Wildが...

5年続いているPerl入学式というコミュニティの運営について

この記事は, 「IT勉強会/コミュニティ運営 Advent Calendar 2016」の5日目の記事です. 今日は, 自分が「校長」という肩書で主催している, プログラミング言語Perlの初心者向け勉強会, 「Perl入学式」について書きます.

perl-entrance.org

Perl入学式とは

Perl入学式は, 2012年に大阪で始まった, プログラミング未経験者や入門者を対象とした, Perlの勉強会です. 単発の勉強会ではなく, 1クール5〜6回のカリキュラムを通して, 環境構築からスタートして簡単なWebアプリケーションの開発までを無料で学ぶことが出来る勉強会になっています.

ざっと概算ではありますが, 年間10〜20人程度の受講生の方がカリキュラムを(ほぼ)完走されるので, 少なく見積もっても2012年から2015年までの4年間で, おおよそ50人程度のPerl Mongerを育てている(?)ことになります.

最近は, Perl入学式をきっかけにしてPerlの会社に転職されるパターン(@htk291さん)も徐々に増えてきていて, 非常に嬉しい限りです.

Perl入学式について, 更に詳しく知りたい方は, こちらのページなどをご覧頂くと良いでしょう:

www.perl-entrance.org

また, 今年も「Perl入学式 Advent Calendar」を開催していますので, こちらもご覧頂けると良いかもしれません:

qiita.com

Perl入学式の運営

2016年のPerl入学式は, 東京, 大阪, 沖縄という3つの地域で開催されています. それぞれ, 5〜10人程度のボランティアスタッフがコアメンバーとして関わっているので, おおよそ30人程度で運営を行っている形です.

私感ですが, これはIT勉強会/コミュニティのコアメンバーとしては異様に多い(例えば, 昨日担当のGotanda.jsの場合, コアメンバーは2人とのこと)と思うのですが, これには理由があります. Perl入学式は, 参加者である受講生に「Perlを教える」勉強会なので, 一般的な勉強会で必要な運営(会場の確保, イベント募集ページの作成と公開, TwitterなどSNSを利用した広報)タスクに加えて, 受講生に提供するコンテンツを作成したり, 勉強会当日に講義を受け持つ「講師」や, 受講生を支援する「サポーター」を確保したり(サポーターによる手厚い支援は, Perl入学式の特色の1つになっています)しなければなりません.

そのため, 少数のメンバーで運用するのではなく, 「Perlを通して, プログラミングの楽しさを知ってもらいたい!」という理念に共感した人を(Perl入学式のカリキュラムを修了した人も含めて)積極的に参加してもらうように心がけています.

こうすることで, それぞれ本業があるメンバーが, 空いた時間を持ち寄って, 動ける時に動ける人が, タスクを分担して消化していくという形で, コミュニティの運営を進めていくことができます.

ちなみに, コアメンバー同士のコミュニケーションはSlack, 情報集約はGitHubを活用しています. この辺りは, 長年いろいろ工夫していたのですが, 最終的にはシンプルな, 必要最低限の形に落ち着いたな, という感じがしています.

Perl入学式と貢献の方法

...さて, Perl入学式において, コミュニティを運営するメンバーを増やしていくことには, もう1つ大きなメリットがあります. それは, 「それぞれの特技や特色を活かせる」というところです.

Perl入学式のカリキュラムを終えた受講生の方に, 「次からPerl入学式のスタッフをやってみませんか?」と言うと, 大抵の人は「いや, 自分はまだ覚えたての初心者で, 受講生に教えるなんて, とても...」と仰る方が多いです. とはいえ, 先ほど述べたように, Perl入学式のスタッフの仕事は「受講生へのサポート」だけではありません. 「初心者だからこそ」出来るタスクも, たくさんあります.

例えば, カリキュラムの改善などはその代表例です. 正直, 何年もPerl入学式をやってくると, 講師やサポーターに「慣れ」というか, 「まあ, これくらい, 省略しても...」みたいな気持ちが生まれてくるのは, 正直致し方ないところがあると思っています.

カリキュラムを終えたばかりの初心者は, そういった点に非常に敏感というか, 気付きやすいと思っていて, 「これって, もう少し細かく説明した方が良くないですか?」とか, 「ここ, わかりにくかったので, もう少しやったほうがいいかも...」とか, カリキュラムの改善に非常に有意義な意見を集めることができます.

また, 本業が編集者であるコアスタッフ(@note103さん)の方もいて, その方はブログエントリや資料の文章を, 非常にいい感じに推敲してくださって, いつも助かっています. さらに言えば, 「仕事をしないスタッフ(主に自分)」のケツを叩くのも立派な仕事だと思っていて, そうやって考えていくと, まさにPerlのモットーである「There is more than one way to do it」, コミュニティへの貢献の方法はいろいろある, だなあと思います.

Perl入学式と懇親会

勉強会において, 懇親会は非常に重要です. Perl入学式でも, 毎回有志を募って懇親会を開催するようにしています. これは実測値ではなく体感値(?)ではありますが, 「懇親会に参加されたことがある受講者」と, 「懇親会に参加されたことがなかった受講者」の, カリキュラムの継続率を比べると, 多分かなりの差が出てくる, ような... 気がしています.

そういった意味でも, 懇親会への参加障壁を下げるのは非常に重要で, 例えば今年は居酒屋で行う「1次会」の前に, 会場で行う軽いピザパーティ, 通称「0次会」という取り組みを行ったりしていました. 詳しくは, こちらのエントリを参考にしてみてください:

perl-entrance.blog.jp

ちなみに, Perl入学式の懇親会は, だいぶカオスな(?)雰囲気がある... ように思います. サポーターや, 仕事でプログラミングをしている受講者の方が, 仕事であった出来事や, 最新技術などのガチな(?)話題で盛り上がっている横で, 声優やらアイドルやらといったサブカルの話題とか, 趣味の話で盛り上がっている, みたいなシーンは日常茶飯事です.

とはいえ, これは非常に大事なことだと思っていて, こうやって講師やサポーターと受講生の皆さんがカジュアルに交流して, 人となりを感じることが出来るからこそ, 次回以降の参加障壁であったり, カリキュラムの中でサポーターに質問する障壁が下がる部分があると思っていて, ワイワイと楽しい雰囲気で懇親会をやる! というところはPerl入学式が非常に大事にしているところの一つです. とはいえ大抵の場合, 毎回いい感じに盛り上がるので, 特段工夫や施策などはしていないのですが.

...ちなみに余談ですが, Perl入学式での懇親会の鉄板ネタはmoznionさんにまつわる伝説の数々で, 本人がいないのに40分くらいmoznionさんの話題で盛り上がるという快挙(?)を成し遂げた結果, 受講者の方から「実際に会ってみたい!」という声が多く挙がり, 実際にPerl入学式の懇親会にご招待したことがあるのですが, いろいろお忙しいようでタイミングが会わなかったのは非常に残念な出来事でした...

Perl入学式と「内輪ネタ」

最後に, 「内輪ネタ」についての話を書きます. IT勉強会やコミュニティにおいて, 「内輪ネタ」についての是非はいろいろ語られていて, 実際にPerl入学式でも, 「この勉強会は内輪ネタが多すぎる!」という感想を頂いたことがあります.

この時は, 割と「どうしたものか...」と悩んだのですが, 結果としては「内輪ネタを薄くするのではなく, 逆に受講者を積極的に内輪に巻き込んでいくようにしよう!」という結論に至りました.

前提として, やはりコミュニティに人が集まると, その中で通用するコンテキスト, 文化, 習慣がどうしても生じてきてしまいます. 例えばPerl入学式では, 声優さんやアイドルのイベントのことを「宗教行事」と呼んでいて, 「その日は宗教行事があるのでサポーター行けません...」みたいなやり取りが頻発したりしています. こういった独自のコンテキストや文化は, コミュニティの特色にもなりますし, コミュニティの内輪にいる人達にとっては大なり小なり楽しく, 面白く感じるものだと思っています.

Perl入学式が, 受講者から参加費を頂いて, それを講師やサポーターに報酬として分配できる形の勉強会ならともかく, 運営について全て手弁当で行っている状況を考えると, こういった要素を撤廃するのは, コアスタッフとしてコミュニティに関わるモチベーションを下げてしまう要因に成りうると思っています. ...というか, これは自分の仮説? 想像? ではありますが, コミュニティからコンテキストや文化, 習慣を消し去ることは, 「コミュニティ」そのものを消し去ってしまうことと同義では? と思っていて, 現実的に不可能なのかもしれません.

だからこそ, IT勉強会やコミュニティを運用するにあたっては, 参加者に対して, 既にコミュニティにいる人達にだけ通用する「内輪ネタ」を押し付けず, 「内輪ネタ」を自然と浸透させて(?), 参加者をコミュニティの内側へ, 「内輪」へ引き込んでいく動きが非常に大事だと思っています.

東京のPerl入学式では, @xtetsujiさんや@ytnobodyさん, @gomaaburamaxなどが, 積極的に受講生とコミュニケーションを取りながら, 自然とそういった動きをしてくださっていて, 非常に助かっています.

なぜPerl入学式が5年も続いたのか?

最後に, Perl入学式という勉強会が, なぜ設立から5年も続いたのかについて考えたいと思います. 結論から言えば, 「コミュニティにおける大事な概念を示せていて, それに則った上でガンガンやっていこう, という文化を作れた」からではないかなあ... と思っています.

Perl入学式では, 「Perlを通して, プログラミングの楽しさを知ってもらおう!」というところを理念として, その為に, 次のような勉強会にしよう! というポリシーを持って運営してきました.

  • プログラミングにチャレンジするにあたって, 最大の障壁は環境構築なので, 環境構築についてはしっかり取り組もう
  • Webアプリケーションフレームワークを使ったWebアプリの開発をやって終わり! ではなく, Perlから他の言語にチャレンジしても活きる, プログラマの考え方や基礎的なところをしっかり教えよう
  • 受講者とサポーター, 受講者と受講者の相互コミュニケーション(質問やアドバイス)によって, 壁を越えられるようにしよう

...まあ, まだこれらのポリシーは完全に実現出来ている! という訳ではないのですが, この辺りの理念やポリシーについては, 5年間やっている中で何となくスタッフの間で「こんなもんだよね」と共有出来ていると思っていて, それによって無駄なやり取りが減っているのは確かだと思っています.

そして, この辺りが概ね共有出来ているからこそ, Perl入学式という勉強会, そしてコミュニティの主催者である自分は, 積極的にタスクをコアメンバーに移譲し, 任せることが出来ると思っていて, 今年は東京/大阪/沖縄の各コアメンバーが, それぞれの地域で上記の理念やポリシーに則りつつカリキュラムを運営し, その中で新しいチャレンジが出来ていると思っています.

勉強会やコミュニティは, 1人で運営できるものではありません(もちろんやろうと思えばできますが, 属人性が高まりすぎて勉強会やコミュニティの持続性が低まってしまいます). だからこそ, コミュニティとして抑えるべきところ(理念やポリシー)はしっかり抑えつつ, それに則った上で, 勉強会やコミュニティのメンバーが, いい感じに動いて「やってみたい!」に取り組める, そういったコンテキスト, 文化, 習慣を作っていくことが大事なのかもしれませんね.

まとめ

Perl入学式という勉強会, そしてそのコミュニティについて綴りました. 勉強会やコミュニティの運営は, 大変なことも多いですが, 楽しいこと, 得られるものも多く, 非常にやりがいがあります.

とはいえ, その「メリット」を目的として勉強会やコミュニティを立ち上げるのは, だいぶ不毛だと思っていて, やっぱり「○○について, 語りたい!」とか, 「××の素晴らしさを伝えたい!」とか, 「△△があったらいいのに, 出来たらいいのに...!」みたいな, そういう「熱い思い」を出発点にするのが良いのかな, という感じはしています. 「努力は夢中に勝てない」みたいな言葉もありますし. ...まあ, だいぶ, というか, かなりの感情論になってしまうのですが...

なにはともあれ, 今後, 皆さんが勉強会やコミュニティを立ち上げる際, この記事で紹介した内容が少しでも役に立てば幸いです. 最後まで読んで頂き, ありがとうございました.

「Fukuoka.pm #27」でトークをしてきました

10月29日に開催されたFukuoka.pmに参加してきました.

fukuokapm.connpass.com

10分ほどお時間頂いて, 最近取り組んでいるhitoboの開発において, LINEのMessaging APIをどのようにして扱っているか, そしてその為に開発した「Primus」という社内ツールについて話してきました.

資料はこんな感じです:

最近のplenv/Cartonの運用

最近のplenvとCartonの運用というか, 「こういう感じでやっていっています」という話です.

あらすじ: cpanm --installdeps .

PerlでWebアプリなど開発する場合, cpanfileに必要なライブラリを指定し, Cartonを使ってcarton installで必要なライブラリをインストールして, 開発を進めていくのが一般的だと思います.

...が, 横着な自分は大抵cpanm --installdeps .を使って, cpanfileで指定されたライブラリをそのままPerlにインストールして開発していくことが多かったのですが, 先日それで痛い目に逢いまして, 「ちゃんとCartonを使ってやっていこう」と心に誓いました.

「きれいなPerl」でCartonを使う

というわけで, コアモジュールとApp::cpanminus, Cartonだけ入った「きれいなPerl」の環境をplenvを使って用意して, これを使って開発していくようにします. また, 間違って(いつもの癖で)cpanm --installdeps .してしまわないように, 「きれいなPerl」の環境は「書き込み不可」にしてしまいましょう.

この辺りは, @tsucchi さんの 僕の perlbrew の使い方の話 - tsucchi の日記 2nd season というエントリで, Perlbrewではありますが, 似たようなことをやっていたので参考にさせて頂きました.

「きれいなPerl」環境を作る

今回は, 今日時点の最新版である5.24.0を題材にやっていきます.

$ plenv install 5.24.0 -- as 5.24-pure
$ PLENV_VERSION=5.24-pure plenv install-cpanm
$ PLENV_VERSION=5.24-pure cpanm Carton

plenv install--asオプションを付けて, 5.24.0を5.24-pureという名前でインストールします. pureは, 「きれいなPerl」という意味を持たせている... つもりです.

あとは, その環境にplenv install-cpanmでApp::cpanminusを, cpanm CartonでCartonを, それぞれインストールすれば, 「きれいなPerl」が出来上がります.

「きれいなPerl」環境をロックする

次は, cpanmでライブラリを勝手にインストールできないように, この「きれいなPerl」環境をロックしてしまいます. Macであれば, 次のようにすればOKです.

$ sudo chflags -R uchg ~/path/to/plenv/5.24-pure

「きれいなPerl」の問題点

あとは, Webアプリのルートディレクトリでplenv localなどを使い, 5.24-pureを指定すれば, 「きれいなPerl」環境の上でWebアプリの開発を進めることができます.

...が, この場合, 言うまでもなく, Minillaとか, App::PRTとか, Pod::Cpandoc::Cacheとか, こういった便利ライブラリは「きれいなPerl」では使えません(「きれいなPerl」環境にはこれらのライブラリはインストールされていないし, ロックしていて新たにインストールできないので).

cpanfileに入れて, carton exec --で動かす, という手もありますが, そういった類のライブラリはcpanfileには入れたくありません.

力で解決: carton-wrapper

解決策はいろいろありますが, 自分は別途plenvで5.24をインストールして, これにMinillaとか, App::PRTとか, Pod::Cpandoc::Cacheとか, 諸々のライブラリをインストールするようにしました. そして通常は5.24のPerlを利用するようにして, cartonコマンドを実行した場合のみ, 「きれいなPerl」, すなわち5.24-pureで動かすようにしました.

このような場合における, plenvでインストールした5.245.24-pureという複数のPerl環境の使い分けについては, こんな感じのcarton-wrapperというスクリプトを書いて, パスを通してalias carton="carton-wrapper"みたいな設定をして, 実現しています.

#!/usr/bin/env perl
use strict;
use warnings;

my $CARTON = $ENV{SCRIPT_CARTON} // "$ENV{HOME}/path/to/plenv/shims/carton";

$ENV{PLENV_VERSION} = $ENV{PLENV_VERSION_FOR_CARTON} if $ENV{PLENV_VERSION_FOR_CARTON};
exec($CARTON, @ARGV);

plenv global5.24を使うように設定した上で, Webアプリのルートディレクトリでdirenvなどを使い, PLENV_VERSION_FOR_CARTON環境変数を5.24-pureにセットします.

cartonコマンドを実行するとcarton-wrapperが呼び出されて, PLENV_VERSION_FOR_CARTON環境変数の値(例えば, 5.24-pureなど)がPLENV_VERSIONにセットされ, これによってcartonコマンドのみ5.24-pureを使って実行されるようになる, という感じです.

まとめ

ここ最近の, plenvとCartonの運用というか, 「きれいなPerl」でCartonを使う為に頑張ったアレコレについて記しました. この辺り, もっと良い方法がある気がするので, ご存知の方は是非教えて頂けるとうれしいです.

「株式会社ガイアックス」の所属ではなくなります

まだ正式な日程は決まっていませんが, 近いうちに所属が「株式会社ガイアックス」から, 子会社の「アディッシュ株式会社」に変わります. ...まあ早い話が「転籍」っていうやつです!

経緯

ありがたいことに, 6月末辺りにアディッシュの社長から「一緒に仕事やろうよ!」と声をかけて頂いて, 7月末あたりからは100%の時間を割いてアディッシュの新規サービスの開発に従事していたのですが, やっているうちにいろいろ心境の変化とかがあって, 今回の決断に至った次第です.

...このあたりは本当に, 4月末からいろいろあった結果の出来事なので, もしこのへんの話に興味があれば🍻などしながら聞き出すと良いでしょう.

今後

本当に「所属が変わる」だけで, 現時点ではアディッシュもガイアックスも同じオフィスで仕事してますし, これまで業務の一環として続けてきたOSS活動(Perl入学式やJPAといったコミュニティ活動も含みます)についても, 続けていけることになっています.

本当に何も変わらないのですが, とは言えこのへんの所属に関する情報は, ちゃんとパブリックに(?)しておいた方が良さそう, ということでブログを書いた次第です.

今やっていること

hitobo.io

hitoboという, チャットボットに関する新規サービスの開発をしています.

...実は, 以前インターンに来てくれた@codehexくんもここのチームで仕事をしてくれていました.

codehex.hateblo.jp

アディッシュ社内はもちろん, ガイアックスグループ全体で見ても平均年齢が若い方な, 非常にフレッシュさが溢れる(?)開発チームの一員として, PerlでAPIサーバを書いたり, AWSを駆使してインフラを整えたり, たまにJavaScriptをいじったりしながら過ごしています.

当面は, この新規サービスの開発支援という形でアディッシュと関わってきましたが, これからはアディッシュ社内に残っているレガシーシステムの改善/置き換えや, 開発基盤の構築, 技術文化の促進や技術広報などにも力を入れていけたらな, という気持ちです.

目標

アディッシュは, 「つながりを常によろこびに」をミッションとして, 「営業」「運用」「開発」が三位一体, 一丸となってやっていっている会社だと思っています. そんなアディッシュの未来を見据えた時に, 「営業」「運用」「開発」の各領域が連携しつつ, それぞれ独自に強くなっていく必要があると感じています.

そのうちの1領域である「開発」の部分を, より強い, 良い組織に前進していけるよう, エンジニアとして先駆けて動いていきたいと思っています. まだまだ至らぬ所も多いですので, 引き続きご指導ご鞭撻の程, よろしくお願い致します.