2018-07-03

ハッカーズチャンプルー2018で、『ソフトウェア開発と私』という発表をしました #hcmpl

6/30 に行われたハッカーズチャンプルー2018で、『ソフトウェア開発と私』という話をしてきました。もともと id:anatofuz さんのお誘いで、ネタは Perl やコミュニティに関する話であればなんでも、ということだったのですが、考えているうちにこれは自分の話になるな、ということで路線変更して、自分のことをふり返った内容にしてみました。面白いと思ってもらえたようでホッとしてます。

ソフトウェア開発と私 / Software Development and I - Speaker Deck

以前インタビューを受けたことがありましたが、その前後で考えたことや、言いきれなかったことをどこかでまとめたいと思っていて、いい機会でありました。それでもまだ全部まとまってるわけではないんですが。あと口頭での内容がメインなので、スライドだけでは分かりづらいところもあるかと思います。

ハッカーズチャンプルー

ハッカーズチャンプルーは初参加でした。沖縄のコミュニティが集まって、それぞれが面白いとおもう発表を用意する、という趣向ですが、たしかに内容の幅が広く、かつ遠すぎず、という感じで楽しめました。ゲストのトークの合間に地元コミュニティからの LT が挟まっているのも楽しくて、すべてがメインコンテンツという感じ。

会場がひとつでワントラックだったのと、小さなスクリーンにツイッターのハッシュタグを映しているのがよくて、一体感もあったと思う。運営の中の人たちからもいろんな話が聞けて、楽しかった。沖縄の人たちは沖縄好きなんだなーってのが伝わってきました。

沖縄旅行記

ここからが本編。

行きの便が那覇空港に着いて、スマホの機内モードをオフにした途端に台風情報が飛び込んできて、それが帰る予定の日曜昼に直撃するってんで、あーどうしようかなと思いつつも、ことの重大さがよく分かっておらず、便の振り替え1泊増やして月曜に帰るかも〜などと会社に間抜けな連絡をしていました。結果的には2泊追加して火曜日の便でいま帰ってます……。

予約していたホテルが風俗街のど真ん中にあって登壇前のナーバスな精神にさらにダメージを受け、引きこもろうかと思いましたが、前夜祭に参加しないわけにもいかないので、街へ出て、先にお土産を買ってから前夜祭へ。開始30分経っても半分しか人が集まっていなかったり、飛び入り LT が続いたりと楽しい会でした。あとこのあたりで沖縄の足はタクシーだなと気づく。

当日土曜日はまだ台風も来てないのに朝から豪雨で、どうなることかと思ったけど開始するころにはきれいに晴れてて何より。本編の話は上に書いているのでいいとして、問題は翌日曜日の飛行機。

ハッカーズチャンプルー楽しかった、明日は何があるか分からないから早起きしよう、と思って寝たところ、欠航の連絡が来ていたらしいと起きてから気づく。

ハッカーズチャンプルー参加してモチベーション上がったけど、寝た直後に欠航の連絡が来てたっぽい #hcmpl
— 美顔器 (@motemen) 2018年6月30日

チェックアウトのときに台風大変ですね、もう今日の夜もこの宿は埋まってますよとフロントで言われて、空港のカウンターでも、今日は飛ばないし月曜日の便まで埋まってます、火曜日もわずか、と聞いてからようやく焦りだしました。関空直通ではないけれど夕方の便が空いていたので取ってみたけれど、間もなく欠航し、これは追加泊決定だな、とあきらめてルートビアを飲みながらホテルを探すも、安宿しかなくとりあえずカプセルホテルが確保できたのみ。

ルートビア、たしかにサロンパスの味。サロンパス食べたことあるからわかる

カプセルかーやだなーと思いながら、ほかの登壇者の動向を探ってみると fujiwara さんの以下のツイートに気づいて、自分も真似してみるとリロードしてるうちにビジネスホテルが確保できた。

なんとかホテル取れた… https://t.co/wtdUr70JxZ で空室出たところで争奪戦してた
— fujiwara (@fujiwara) 2018年7月1日

booking.com には Perl の神様がついている。ホテルで予約がちゃんと通っていることを確認して荷物を預けるとようやく沖縄を楽しむしかないと思えてきて、少し観光する余裕が出てきました。本場の台風たのしかった。また本州で会おうな。

あきらめて沖縄満喫してる

月曜日の日中はふつうに仕事。ハッカーズチャンプルー後夜祭が開かれるとのことで当然参加したけどこの人たちと何度飲んでるんだろと思って面白かった。発祥の店のタコライスを食べられたのに感激しました。

ハッカーズチャンプルー後夜祭してる #hcmpl

いまは朝イチの便で関空に向かってます。ここまで来るともう安心でしょう。いろいろと大変でしたが、最終的にはすべていい思い出です。

2018-05-08

AWS AppSync で時刻のソースをエポックミリ秒として扱いたい

GraphQL

サーバレスで GraphQL したかったので AWS AppSync に入門してみた。スキーマを書いてデータソースとリゾルバを追加して……というフローでずいぶんさくさくと進むんだけど、タイトルに書いたとおり時刻をエポックミリ秒として扱おうとすると困ってしまった。

つまり以下のようなスキーマで、データソースに格納されたエポックミリ秒（例えば 1503932400000）を JSON にして返そうとすると:

type Entry {
  createdAt: Int!
}

こんな感じのエラーになってしまった。

{
  "data": {
    "getEvent": {
      "createdAt": null
    }
  },
  "errors": [
    {
      "path": [
        "getEvent",
        "createdAt"
      ],
      "locations": null,
      "message": "Can't serialize value (/getEvent/createdAt) : Expected type 'Int' but was 'Long'."
    }
  ]
}

なるほどね、と思ったものの GraphQL に Long 型はない。調べてみると、数値が 2147483648 以上になるとリゾルバの内部で Long 型として扱われるように見える。

これは型が Int のフィールドにローカルのリゾルバ（type が None のもの）をアタッチし、request mapping template を

{
    "version": "2017-02-28",
    "payload": 2147483648 ## または 2147483647
}

のようにして確かめることができる。

ミリ秒をあきらめてエポック秒にすればこの境界を越えないわけだけど、せっかくなのでこういう風に解決してみた:

createdAt フィールドが引数を取り、文字列型を返すようにする。

type Entry {
  createdAt(format: String, timezone: String): String!
}

上記 createdAt フィールドにローカルのリゾルバをアタッチし、request mapping template を以下のようにする。

#set($format = $util.defaultIfNull($ctx.args.format, "yyyy-MM-dd HH:mm:ss"))
#set($timezone = $util.defaultIfNull($ctx.args.timezone, "+09:00"))
{
    "version": "2017-02-28",
    "payload": "${util.time.epochMilliSecondsToFormatted($ctx.source.createdAtEpochMillis, $format, $timezone)}"
}