Masteries

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

YAPC::Kansai, お疲れ様でした!

YAPC::Kansai, お疲れ様でした. YAPC::Hokkaidoに引き続き, 今回も非常に良いYAPC::Japanでしたね! 大阪と言えば, 自分が生まれ育ち, そしてPerlを学んだ思い入れの深い地元です. ここでYAPC::Japanが開催されるというのは, 本当に感慨深いものがありました.

前回のYAPC::Hokkaidoに引き続き, 一応スタッフということで参加はしていたのですが, 実際のところ座談会にトークに... と慌ただしくてそこまでスタッフとして働けなかったのは心残りでありました. その代わり(?), 今回は本当にいろいろなイベントに絡むことができたので, そのへん紹介しつつ, YAPC::Kansaiの感想エントリにしたいと思います.

前夜祭に出ました

前夜祭のコンテンツである, 「突撃!隣の開発環境!」のトップバッターをやりました.

とにかくzshのaliasは改めて設定ファイル眺めてみると自分自身「ひどいな!!!」と言わざるをえない... というわけで, 近々あまり使ってない/覚えてないaliasはサッパリ整理していこうと心に刻みました. あと記憶に残っているのは弾さんのツッコミ(Dan the interruption)で, 初体験(?)だったので, とにかくリズムを崩されっぱなしでした. 精進しないといけませんね...

割と(大阪らしい!?)ハチャメチャな部分もあった前夜祭ですが, いろいろと印象に残ったというか, 勉強になったことも多かったです. 例えば@songmuさんが紹介していた.tigrcとかもそうで, ここ最近なるべくtigを使っていこうと試みていたので, めっちゃ参考になりました. というかtigって設定ファイルあったのか...

座談会をしました

Perl入学式座談会 〜これまでの軌跡を振り返り, そして未来へ〜」という座談会に登壇しました. 今回は自分に加えて, 古参枠(Perl入学式の始まりを知っている, 初期メンバーの1人)であるところの@azumakuniyukiさん, そして受講者からスタッフ/サポーターになった枠として@gomaaburamaxの3人で, Perl入学式についてのアレコレを語りました.

ちなみにこの座談会, 当初は自分が司会をするつもりだったのですが, 「papixが司会をすると, 延々とpapixが喋って座談会ではなくなってしまう」などの懸念が登壇者の一部から出た為, 急遽@crazygirl_loverさんに司会をお願いすることと相成りました. 結果としてこの選択は大正解だったと思っていて, 2年前のYAPC::Asiaにおける若手座談会でも発揮された定評のある司会力で, 5年目の終わりを間近に迎えていよいよ6年目(!?)を迎えるPerl入学式にとって, 「過去を, 今を, 未来 繋げる」良い節目になったのではないかな, と思っています.

トークをしました

PerlのWebアプリケーションをデプロイする時に僕達が考えたこと」というタイトルでトークをしました. 今回はちょっと反省点が多かったと思っていて, 特に20分だとどうしてもデプロイについての概論的な部分でいっぱいいっぱいになってしまって, 具体的な内容に踏み込めなかったのは悔いが残るところでした...

とはいえ, 発表資料をまとめている中で自分自身の経験も整理することができたので非常に有意義でしたし, 特に学生さんや, 趣味でプログラミングをしている方にとって, 「Webアプリケーションのデプロイ」は小さくない壁だと思っていて, そういった所にチャレンジする際の指針を考える資料としては役立てるのではないかと期待しています.

次にこういった内容で発表をする時は, 勇気を持って40分で応募して, 20分で概論を語り, 残り20分で概論を踏まえた実践的な(実務的な)内容に触れられるような構成に出来たらいいなーと思います.

トークを聞きました

利用しているBaaSが終了するときにすべきこと または Parse.com の終了と私たちの取り組み by @side_tana

とにかく壮絶といった感じで, MBaaS(Parse.com)に依存したサービスが, MBaaSのクローズに伴ってどのようにMBaaS依存から脱却していったか, その実態が語られていてとても興味深かったです.

トークの中で「MBaaSの利用は借金」と仰っていて, まさにその通りだと思うし, 利率は違えど(?), IaaSやPaaSの利用もノーリスクではなく, ある種の借金であることには違いないと思うので, そういった観点を持った技術選定って大事だなあ, と改めて思いました.

カヤックのゲーム開発・運用の「今」 力技と効率化の先に我々が目にしたものとは by @mackee_w

めっちゃ良かった. 特にトークの順番が良かったと思っていて(?), 自分のトークで自分自身がデプロイのついての概論を語って振り返った後で, こういった実際の風景を見れると, より深く理解出来た気持ちになって良かったと思います.

あとは質疑応答で, 「こういった自動化や効率化は属人化しがちだけれど, どう対処している?」という感じの質問に対して, 「少し穴を残しておいて, そこを突っ込まれたら"じゃあやってみて!"と丸投げする, そうやって自動化や効率化のためのコードに触れてもらって, 慣れていってもらう」みたいな答えをしていて, これはまさに目から鱗, 逆転の発想という感じで, 非常に感銘を受けました.

Webエンジニアに知ってほしいRDBアンチパターン by @Soudai

RDBのアンチパターンに関して, 具体的な例も織り交ぜながら解説していくという感じのトークで, 非常にタメになりました. ファントムリードやダーティリードは「りろんはしってる」という感じで, きちんと理解出来てる自信がないので, 改めて理解に努めようと思いました...

それからなんといっても, ベストトーク賞おめでとうございました! 参加者による投票形式で, B部屋というキャパシティが少ない会場だったにも関わらず, ベストトーク賞を受賞するというのは本当に凄いことだと思っていて, とにかく凄く凄いです!

なんと同じ会社の一員になることができたので, この辺りのRDBの話題, いろいろと伺えたらいいなーと改めて思いました.

そしてYAPC::Fukuokaへ...

無事YAPC::Kansaiが終わり, 次はいよいよYAPC::Fukuokaです. 既にティザーサイトが公開され, チケットの販売やトークの募集も開始しています.

yapcjapan.org

YAPC::Fukuokaは現地のFukuoka.pmとJPAの協力のもと開催される訳ですが, 実はYAPC::FukuokaについてはJPA側の代表が自分という事になっていて, Hokkaidoからスタートして, Kansaiに渡ったバトンを私達が受け取り, Fukuokaの次であるOkinawaへと繋ぐ, 重要な役割を担うことになりました. まだまだ至らぬ点も多いですが, 実行委員長である@debilityさん, そしてFukuoka.pmの皆さんやJPAのスタッフと協力しながら, YAPC::Fukuokaの開催に向けて, 頑張っていきたいと思っています.

...それではまた, 7月に福岡でお会いしましょう!!!

YAPC::Kansaiで逢いましょう!

いよいよ今週末はYAPC::Kansaiですね. 地元関西で初のYAPC::Japanということで非常に楽しみです.

yapcjapan.org

トークをします

14:50〜15:10にB会場で, 「PerlのWebアプリケーションをデプロイする時に僕達が考えたこと」というトークをします.

裏番組がdankogaiさんとmoznionさんのスペシャルセッションという事で, 誰も話を聞きに来ないのではないかという予感が一瞬脳裏をよぎりましたが(正直自分もスペシャルセッション見に行きたい), とにかく頑張ってやっていきます.

業務でPerlを使ってWebアプリケーションを作っている人からすれば, デプロイは日常茶飯事な出来事ではあります. しかしながら趣味でPerlをやっている人からすれば「Webアプリケーションのデプロイ」は割と未知の領域なのでは? という感じがしていて, Perlを学んで, Webアプリを作れるようになって… の次に立ちはだかる壁が「デプロイ」になっていると思っています.

そういった方の後押しになるよう, このトークでは, 趣味で作るような小規模なPerl製Webアプリケーションにおけるデプロイ戦略などのネタを中心に, デプロイに関するアレコレをお話していきたいと思っています.

座談会をします

12:10〜12:50に, C会場で「Perl入学式座談会 〜これまでの軌跡を振り返り, そして未来へ〜」という座談会がありますが, こちらにも出ます.

座談会の司会進行については, 当初自分がやるといった話もあったのですが, 「ずっとpapixが喋ってしまって, 座談会でなくなってしまう懸念がある」というツッコミが入った為, 「ジンジニア」こと@crazygirl_loverさんにお願いすることにしました.

ジンジニアさんは以前, YAPC::Asia 2015における若手座談会でも司会進行をしてくださっており, その手腕には定評と実績があるので, 至極真っ当な座談会が繰り広げられるのではないかと思います.

裏番組であるところのmoznionさんの「Webアプリケーションのキャッシュ戦略とそのパターン」も絶対聞きたいトークの1つだったのですが, ぐっと我慢してPerl入学式のこれまでやこれからを座談会形式で語っていきたいと思いますので, Perl入学式というコミュニティの歴史やその運営に興味がある方は足を運んで頂ければ嬉しいです.

なんと前夜祭にも出ます

なんと, 上記のトークと座談会に加えて, 前夜祭のコンテンツであるところの「突撃!隣の開発環境!」にも参加することになっています. 正直, そんな凝った開発環境ではないのですが, 酒の肴になるよう盛り上げなど頑張っていきたいと思います.

YAPC::Kansaiでpapixと握手!

それでは皆さん, YAPC::Kansaiでお会いしましょう! …なお資料の進捗は0%です, 本当にありがとうございました.

DateTime::Format::MySQLで作ったDateTimeオブジェクトにタイムゾーンを設定するとエラーになる場合がある

i18n対応したサービスをDateTimeを使ってモリモリ開発している方からすれば既知な話かもしれませんが, 自分は知らなかったのでメモ.

DateTimeとタイムゾーン

DateTimeは, かなりしっかりとタイムゾーンに関する処理が実装されています.

use feature 'say';
use DateTime;

my $dt1 = DateTime->now();
print $dt1->time_zone(); # => UTC

my $dt2 = DateTime->now(
    time_zone => 'Asia/Tokyo',
);
my $dt2->time_zone(); # => Asia/Tokyo

このように, DateTime->new()DateTime->now()において, time_zoneでタイムゾーンを指定すると, 指定したタイムゾーンがセットされたDateTimeオブジェクトを生成することができます(指定しない場合, UTCとして扱われます).

更にDateTimeのオブジェクトは, set_time_zoneメソッドでタイムゾーンを変更することができます.

use feature 'say';
use DateTime;

my $dt = DateTime->now( time_zone => 'Asia/Tokyo' );
say $dt->time_zone->name; # Asia/Tokyo
say $dt->strftime("%F %T"); # 2017-02-13 19:00:00

$dt->set_time_zone("Europe/London");
say $dt->time_zone->name; # Europe/London
say $dt->strftime("%F %T"); # 2017-02-13 10:00:00

サービスの多言語対応などで, ユーザーのタイムゾーンに応じて時間を出し分けたい場合, このset_time_zoneによるタイムゾーンの変更機能は非常に便利です.

DateTime::Format::MySQLについて

さて, DateTime::Format::MySQLを使えば, 次のようにしてMySQLのフォーマットからDateTimeのオブジェクトを生成することができます.

use feature 'say';
use DateTime;
use DateTime::Format::MySQL;

my $dt = DateTime::Format::MySQL->parse_datetime("2017-02-13 19:00:00");
say $dt->time_zone->name; # floating
say $dt->strftime("%F %T"); # 2017-02-13 19:00:00

この時, $dtのタイムゾーンはfloatingになっています. DateTime::Format::MySQLのドキュメントを見ると, 次のように書かれています:

This class offers the following methods. All of the parsing methods set
the returned DateTime object’s time zone to the floating time zone,
because MySQL does not provide time zone information.

要するに, MySQLではタイムゾーンに関する情報を提供していないので, floatingというタイムゾーンとしてDateTimeオブジェクトを作っている, という訳です.

use DateTime;
use DateTime::Format::MySQL;

my $dt = DateTime::Format::MySQL->parse_datetime("2017-02-13 19:00:00");
$dt->set_time_zone("Asia/Tokyo");
say $dt->time_zone->name; # Asia/Tokyo
say $dt->strftime("%F %T"); # 2017-02-13 19:00:00

このように, DateTime::Format::MySQLで生成したDateTimeオブジェクトに, set_time_zoneメソッドでタイムゾーンを指定すれば, 任意のタイムゾーンのDateTimeオブジェクトが取得できます. 上記の例の場合, Asia/Tokyoタイムゾーンにおける2017-02-13 19:00:00のDateTimeオブジェクトが取得できるわけです.

DateTime::Format::MySQLで作ったDateTimeオブジェクトにタイムゾーンを設定するとエラーになる場合がある

…いよいよ本題です. 論より証拠ということで, 実際のコードを見てみましょう.

use feature 'say';
use DateTime;
use DateTime::Format::MySQL;

my $dt = DateTime::Format::MySQL->parse_datetime("2017-03-26 01:00:00");
$dt->set_time_zone("Europe/London");
say $dt->time_zone->name;
say $dt->strftime("%F %T");

このコードを実行すると, 次のようなエラーになります.

Invalid local time for date in time zone: Europe/London

サマータイムの罠

原因は, 英国夏時間です. Wikipediaによると, 英国夏時間は次のような仕組みになっているそうです:

具体的な実施期間は、3月最終日曜日1時(UTC)から10月最終日曜日1時(UTC)までの期間。つまり、グリニッジ平均時で3月最終日曜日の1時になった瞬間、英国夏時間が始まり、同日の2時になる。また、英国夏時間で10月最終日曜日の2時になった瞬間、グリニッジ平均時に戻り、同日の1時になる。このため、夏時間の開始日は1日が23時間となり、終了日は1日が25時間となる。

要するに英国夏時間において, 3月26日午前1時0分〜3月26日午前1時59分は存在しないわけです.

そのため, 上記のように, floatingタイムゾーンにおける2017-03-26 01:00:00のDateTimeオブジェクトに対してset_time_zoneEurope/Londonを指定すると, DateTimeオブジェクトはサマータイムによって存在するはずのないEurope/Londonタイムゾーンにおける2017-03-26 01:00:00になるようにタイムゾーンを書き換えようとします. そのために, 先程のようなエラーが表示されるのでした.

まとめ

これまで割とサマータイムもなく, 特段タイムゾーンを意識しなくてよいJSTの世界に閉じこもって(?)コードを書いていたので, 今回のタイムゾーンやサマータイムの話は調べることがいろいろあって学びがありました.

タイムゾーンやサマータイムの扱い, 非常に難しいものがありますが, 引き続き頑張っていきたいものです.

株式会社はてなに入社しました

株式会社はてなに入社しました.

何をするの?

ブログをします. つまり"これ"です.

どこで働くの?

東京です. …が, 今日から2週間ほど京都で研修をしています受けています.

どうしてはてなに入社したの?

いろいろな経緯があって入社したのですが, それを書くには時間が少なすぎました…(意: これから🍻).

まとめ

抱負とか, あるいは実際に入社して感じた感想などは, おいおい綴っていきたいと思います. とりあえず, 入社のご報告ということで…

引き続き, はてなでも頑張ってまいりますのでよろしくお願いいたします.

2016年の振り返り

あけましておめでとうございます. 今年もよろしくお願い致します. というわけで年始恒例の振り返りブログです. 今年もKPTを使ってやっていくことにしましょう.

Keep

「2016年にやってみてよかったこと, 2017年も継続して取り組みたいこと」

いくつかツールを公開できた

業務向けに作ったものを汎用化して公開するという流れで, CPANにAnegoをDeveloper Releaseしたり, Primusを公開したりできました.

とはいえ, いずれもちゃんとドキュメンテーションできておらず, AnegoはそのためにDeveloper Releaseのままなので, 早いうちにドキュメントを仕上げたいと思います...

Go言語にチャレンジできた

前述のPrimusは, 当初はPerlとNode.jsで実装していたのですが, GitHubで公開するにあたってGo言語で書き直しました. 2016年はGo言語にチャレンジしたい! と思っていたので, 最後の最後に成果物を出せて良かったです.

また, Go言語にチャレンジするにあたっては, 運良く(?)ご恵贈頂いた「みんなのGo言語」が非常に勉強になりました. 僭越ながら書評も書かせて頂いたので, ご興味ある方は是非読んでみてください.

papix.hatenablog.com

雑誌に記事を書く機会があった

いろいろなご縁があり, 技術評論社の「Software Design」や「WEB+DB PRESS」に記事を書く機会が4回もありました.

自分のやってきたこと, そこから得た知見や気付きを文章でまとめるという行為(?)は, これまでこのブログで延々と続けてきたことではありますが, それを「雑誌に載せる」という形で行うのは言うまでもなく始めてのことで, 本当に苦労の連続でした.

@inaoさんをはじめ, 技術評論社の皆様には本当にお世話になりました. この場を借りて, 改めて御礼申し上げます. 本当にありがとうございました.

久々にYAPCで発表できた

papix.hatenablog.com

RebootしたYAPC::Hokkaidoで, 「APIをPerlで作る時に僕達が考えたこと」というトークをしました. 「これ, 割と常識的な内容なのでは...」と尻込みしていたのですが, 予想以上に多くの方にお聞きいただいて, Twitterでもたくさん感想やご意見を頂けましたし, 何より@tagomorisさんからはYAPC::Hokkaidoの感想エントリでお褒めの言葉まで頂戴することができ, 本当に嬉しかったです.

...そういえば, YAPC::Hokkaidoの感想エントリ, まだ書いてませんでしたね. が, がんばります...

昨年に引き続き, アウトプットを続けられた

2016年は, このブログに32件のエントリを投稿しました.

また, 春から夏あたりにかけて, 一時期Qiitaを併用して, こちらにも記事を投稿したりしていました.

これは個人的な感想(?)なのですが, 何故かQiitaに記事を書く時は異様に記事を作り込んでしまう傾向があり, このブログほど気軽に投稿できず, ネタのストックが増えていく... という状況に陥ってしまいました. そのため, 秋辺りからはQiitaの併用を辞めて, 再度このブログに一本化したりしていました. そのため上記の記事も, どこかのタイミングでマスターをこのブログに移す... かもしれません.

Perl入学式の5年目も無事終わりそう

2016年は「in東京」, 「in大阪」, 「in沖縄」の3拠点での開催となりましたが, いずれもしっかりゴールを迎えられそうです. また, 年末のPerl入学式 Advent Calendar 2016も, 無事完走することができました.

2017年は, 年始にJPAのブログでお伝えしたように, JPAとの連携を深めて, 新しい施策を幾つか動かしていきたいと思っています. 引き続き, 「Perlを通じて, プログラミングの面白さを感じてもらえる勉強会」になるよう, 頑張っていきたいです.

blog.perlassociation.org

新しいチャレンジがたくさんできた

上記以外にも, 今年はいろいろなイベントやチャレンジがありました.

機動力が高いというか, 身軽にアクションしていくというところは自分の持ち味の一つ(その裏に, "飽きやすい"という弱点はあるのですが...)だと思うので, 2017年もいろいろなチャレンジをしていきたいです.

Problem

「2016年で良くなかったところ, 2017年に改善していきたいところ」

メンタル的(?)な波の振れ幅が大きかった

2016年は, 自分にとって良いイベントも悪いイベントもたくさん起きて, それに引きずられて精神面はだいぶ波がある1年でした. また, それに伴ってインプット/アウトプットについても, 非常に捗る時期と非常に停滞する時期が, 繰り返し来ていたように思います.

とはいえ, そうやって精神的な状態が揺れ動いている間に, 自分自身について改めて向き合う機会があり, そこでいろいろと気づけたのは非常に良かったです(この辺の"気付き"については, 振り返りを兼ねて自分の言葉で綴りたいと思ってはいるのですが, 抽象的な部分も多くて, なかなか難しいですね...).

どうしても, 人間感情を持っていて, その波を常に一定に保つのは難しい(無理?)とは思います. とはいえ, 2017年は2016年の気付きを活かして, できる範囲で自分自身のメンタルをコントロールして, 安定したアクションが出来るといいなと思います.

Mackerel User Groupの活動があまりできていない

Mackerel User Groupを立ち上げたはいいのですが, あまり活動できておらず... 申し訳ないところです. 特に, 夏に大阪で開催予定だったMeetupが, 台風の接近で中止になってしまったのは痛恨でした.

とはいえ, Mackerel User Groupが目指している「ユーザー間の情報共有」という部分は, Mackerel User GroupのSlackで実現出来ている部分が大きいので, 引き続きこれを盛り上げつつ, Mackerel User GroupのMeetupも開催していきたいと思います.

ちなみに, Mackerel User GroupのSlackはこちらのslackinからジョインすることができます: Join mackerel-ug on Slack!

Try

「2017年, 改めてチャレンジしていきたいところ」

もっとGo言語を!

言うまでもなく(?)引き続きPerlをやっていくつもりですが, 2017年は並行してGo言語もしっかり取り組みたいです. 題材として, ローカルの開発環境で使っているPerl製の「便利スクリプト」のGo言語への移植とか, (実際に公開するかはともかくとして)schemalexを利用したGo言語版のAnegoとか, ネタはいくつかあるので, ちまちまと取り組んでいきたいです.

最終的に, Primusのようなツールの公開や, mackerel-agentのようなGo言語で作られたツールへのコントリビューションが出来ると良いですね!

新しい職場で"やっていく"

papix.hatenablog.com

2016年最後の大きなトライがおおよそ2年半勤めてきたGaiaxの退職だとすると, 2017年初の大きなトライは間違いなく2月1日からの「次の職場」への入社になると思います.

詳細はここでは述べませんが, 正直に言えば今回の転職は(個人的には!)"ハイリスクハイリターン"だと思っています. 今回の転職によって得るものは多いけれども, そのためにはGaiaxにいた頃の120%, 130%の力を発揮していくことが求められてくる... と思っています. 新しい職場に慣れ, 職場での信頼関係を構築していくというところを含めて, この辺りうまく適応出来るか? というところは, ある種の"リスク"と言えるのではないでしょうか.

とはいえ, 今回はそういった職場だからこそ出来るチャレンジがあり, そこから学べることがあると自分は信じています. 今回の転職については, 経緯からしても割と「勢い」によるところが大きかったりはするのですが... なにはともあれ, 選考の結果として入社が決まり, Gaiaxを退職して2月から新しい環境へ「飛び込んでいく」のは, もう確定事項です.

明日朝起きたら, これまで出来ていなかった事が出来るようになっている... みたいな, 都合の良い出来事は起こり得ないので, まずは今やっていること, 今出来ることをしっかりこなしながら, 新しい環境に慣れていきたいと思います. 当面の目標は, 試用期間をしっかり乗り切ることですね...!

まとめ

というわけで, 2016年の振り返りでした. 本当に, 公私共々いろいろな出来事があった1年でしたね... 今年も転職を含めて, いろいろありそうな予感が現時点からしているので, へこたれず, 元気いっぱいにやっていきたいと思います.

今年もまた, ご指導ご鞭撻頂けますと幸いです. 2017年もどうぞ宜しくお願い致します!