結論からいうとたくさん人がいてオフライン参加楽しいなと思いましたが、まだ見ていないセッションをニコ生で見る日が続きそうなので今のうちに覚えていることを書こうと思います。

LTのペンライトが楽しい

色んなカンファレンスでたいていはLTの時間があると思いますが、こちらは終了時間が迫ると発表者の推しの色のペンライトを振る、という視聴者参加方のLTで、みんなが振ると綺麗だし、一体感があってよかったです。もちろんLT自体の内容もかなり幅広くおもしろかったです。ピンチヒッターでおなじみのあの方が出てきて結構テンションがあがりました。

オフライン参加でもニコ生は使う

トラックが最大4つあるので、同じ時間に見たいトークがかぶる、という時が何度かありました。自分は事前にプレミアム会員登録をしておいたので、タイムシフト予約をしなくとも空き時間や帰ってから見たかったやつをすぐ見られてよかったです。まあ最初からYouTubeの方がいい、という説はありますけど、LTの時なんかは特にコメントが結構流れるので元ニコ厨としては懐しさがあってよかったです。

久々の無限コーヒーがうれしい

カンファレンスといえば永遠におかわりできる無限コーヒーなんですが、久々のオフライン参加でこれに出会えたので初日はトークの度におかわりするくらいの勢いで飲んでいました。朝は個数限定ですがミスドのドーナツもあるので、最高の組み合わせではと思います。

サーロインアボカド弁当うまかった

最終日のキッチンカーで売ってましたが、野菜も入ってるし量もそこそこあってよかったです。来年も食べたいです

懇親会で話してくれた人に感謝&すみません

一人で参加したし知り合いもあまりいないので、酒の力で何人かに話しかけましたが相手してくれてありがとうございます。途中ちょっと声がでかくなってたのは覚えていて、すみませんという気持ちです。というかもっと色んな人と話してみたかったし、スタッフさんとも話してみたかったりします。

コードレビューの企画、おもしろそうだった

ぶっちゃけスポンサーブースに全然行けてないですが、唯一、たしかLINEさんのブースで、書かれているコードにレビューのコメントを付箋で貼る的なのをやっていて、他の人のコメントを読むのが面白いし、いい企画だなと思いました。まああからさまにおかしいものはコメントも限られてきますが、もっと全体を見ないと分からなそうなコメントをしてる人もいて、その辺がおもしろいなと思いました。

こまかい気配りがある

分厚いパンフレットや大きいノベルティの箱は何歳になってもわくわくするものなのでいいんですが、会場にはぶっちゃけ重くて持ってこないので、毎日その日だけのタイムテーブルが載ったパンフレットを配ったりしてくれるのはちゃんと考えられてていいなと思います。

あと部屋が混んできた時にもっと人が入れるように詰めてもらうのも「自分の右側が空いていれば詰めて」という分かりやすい指示の出し方でいいなと思います。

トーク&ポスターセッション良かった

まず自分が本業でiOSをやるようになって、今回は自分の仕事でやっていることに関係のあるものを選んで聞きにいっていたので、以前よりかなり自分ごとが多くてそれだけでどのトークもおもしろかったです。

今回は事前に時間帯ごとに見るものを決めてタイムテーブルで星をつけておいたので、聞きたかったやつは全部聞けた気がします。

まあ全部良かったんですが、前夜祭は shimastripe さんのこの発表が分かりやすくてよかったです。まだ UIKit の部分はかなりあるので多分お世話になる気がしています。あと内容関係ないけど声がよくて聞き取りやすいなと思いました。

UIKit ベースの Custom UIContentConfiguration API を用いた複雑なカスタムセルの作り方

1日目は唯一、 Ask the speaker で質問に行ったのでこちらが印象に残っています。一方的に質問して教えてもらいましたが、他社の人に教えてもらっただけでこちらから返せるものはないが大丈夫なのか…?と不安になってきました。とりあえず林さんありがとうございました。

SwiftUI + KMM 開発で見えたそれぞれの長所と短所

最終日は、自社アプリではちゃんと Xcode Preview をまだ使えていないので、まつじさんのこの発表のアイデアが普通にすごいなと思ったし、実際に使いたいと思いました。最初からソースコードなども公開された状態で話が始まったので、クローンしたコードを見ながら話を聞けたのがよかったです。

Xcode Previewを気軽に利用するためのDI戦略

ポスターセッションも色々あって全部は書けないんですが 417.72KI さんのブランチ運用の話を聞いてうちも近いかもと思ったり、ひめしさんのUserDefaultsに暗号化していれる話でなるほどーとなったり、去年めちゃくちゃ幕間に見た気がするuhooiさんのコードが読めたりしました。

他にも色々ありますが全時間分書くのは大変なのでここまでにします。

来年も開催してほしい&行きたい

とてもいいイベントなので来年もオフラインで参加したいです。そういや全日マスク着用だったので来年はマスクなしでできる状況であってほしい…!

そして6月末に、この Angular の最新バージョンである 10 がリリースされました 🎉。今回はその追加要素の1つである Date Range Picker についてとりあげたいと思います。具体的にいうと、裏側を知ろう、ということで愚直にコードリーディングをしてみました。そこで分かったことをまとめたいと思います。

Date Range Picker とは

Angular の UI ライブラリである Angular Material に追加された、日付の範囲(開始日と終了日)の選択ができる UI コンポーネントのことです。

細かいことをいうと、日付を選択できる Datepicker というコンポーネントが元々あり、それを日付の範囲選択にも対応させたもののことを Date Range Picker と呼んでいます。

Angular 10 のリリース内容については Version 10 of Angular Now Available にまとまっていますが、最初にこのコンポーネントの説明があります。

また実際の動作を見たい場合は、上のリンクの記事からも参照されている 公式ドキュメント でコード例と合わせて動作サンプルを見ることができます。

コードリーディングのやり方

ここで実際にどうやってコードを読んだのかについて先に説明しておきます。ただ、私が Angular 公式(?)のコードを読んだのは実は今回がほぼ初めてなので、効率的な読み方といった話ではなく、あくまでも実際にやった方法の話になります。方法としては

1. Google Open Source の該当ディレクトリでまずオンラインで読む
   (もちろん GitHub でも読めるのですが、こちらの方がある程度読みやすいと思います。この ng-japan OnAir の放送 で知りました)
2. あまりにもややこしいので読むのをあきらめる😩。というのは半分冗談で、ソースをダウンロードして、ローカルの開発サーバで実際に動かし、Webブラウザのデバッガでブレークポイントを置くなどしてややこしい部分の挙動を確認する

2 は具体的にはこのようにやりました:

1. Angular 10 のプロジェクト(スタイルはscssを利用)を作成する
2. Angular Material をインストールする
3. Github から同じバージョンの components のソースをダウンロードし、src/material の中の datepicker ディレクトリだけを丸ごとプロジェクト内にコピーする

これだけだとビルドができないので、更にこちらの修正をしました:

• .ts 内で .css を参照している場所を .scss に書き換える
• .scss 内の @import '../../cdk を @import '~@angular/cdk に書き換える
• .scss 内の@import '../core を@import '~@angular/material/core に書き換える

最後に AppModule 等でこの datepicker ディレクトリから MatDatepickerModule をインポートしておけば、テンプレート内で Datepicker のコンポーネントを使うことができます(正確には MatNativeDateModule のインポートも必要です)。また当たり前ですが ローカルにソースコードがあると普段使っているエディタで定義ジャンプなどができて読みやすくなります。

今回注目して読んだところ

上の Google Open Source の該当ディレクトリのリンク先を見てもらえば分かるのですが、Datepicker に関するファイルは約 50 ファイル程あります。なんと私はこれらを全て読みました😤。…というのは嘘で、仮に読んだとしてもこの記事で触れるには量が多過ぎるので、気になるところに注目して読むことにしました。

具体的にはドキュメントの「Date range input forms integration」のサンプルをややシンプルにした以下のコードの各要素について、それぞれどういう関係にあり、どのようにデータをやりとりしているのかを見ていきます。

ちなみにこのコンポーネントの TS ファイルはこうなっていますが、 rangeという FormGroup を用意している以外に特筆すべきことはありません。

Date Range Picker の理解に必要なファイル6選

以下にコード例と実際のUIの対応を図にしてみました。

基本的な構成として、まず青枠の mat-date-range-picker (以下、ピッカー)が全体を管理するコンポーネントになります。このコンポーネント自体は裏方的な役割で、画面に表示されません。このピッカーが表示する mat-datepicker-content が日付を選択するためのカレンダー式のUIになります。(なお緑枠の mat-datepicker-toggle はカレンダーの表示をトグルするためのコンポーネントです。他に特に説明することがないため今回は取り上げません。)

赤枠には複数のコンポーネントがありますが、メインは mat-date-range-input で、その下に matStartDate と matEndDate のディレクティブが付加された input があります。アプリケーションの他の部分とデータのやりとりをするのがこのインプット群で、ピッカーで日付を選択すると FormGroup の値に反映され、逆に FormGroup の値が更新されたり、テキストフィールドから直接日付を入力した場合はそれがピッカーに伝えられます。

そのやりとりに使われているのが MatRangeDateSelectionModel のオブジェクトで、ピッカーで通常は生成され、インプットやカレンダーUIにその参照を渡すことで共有します。

これが全体像で、対応するファイルは以下のようになっています:

• mat-date-range-picker … date-range-picker.ts
• mat-datepicker-content … datepicker-base.ts
• mat-date-range-input … date-range-input.ts
• matStartDate と matEndDate … date-range-input-parts.ts 、datepicker-input-base.ts (継承元)
• MatRangeDateSelectionModel … date-selection-model.ts

それでは次に一番重要な mat-date-range-picker を見ていきます。

MatDateRangePicker とジェネリック型 S、D

mat-date-range-picker.ts を開いて mat-date-range-picker のクラスを見てみます。このファイルは執筆時点のバージョンでたったの46行しかありません。なんだかすぐに読めそうで、良かったですね。ただしクラスの最初の行を読めば分かる通り MatDatepickerBase を継承していて、これが定義されている datepicker-base.ts は最新バージョンで654行あります。

export class MatDateRangePicker<D> extends MatDatepickerBase<MatDateRangePickerInput<D>, DateRange<D>, D>

実は MatDateRangePicker の処理は、以前から存在している単一の日付選択用の MatDatepicker とほぼ処理が共通で、それらが MatDatepickerBase に書かれています。ちなみに MatDatepicker のクラス定義はこちらです。

export class MatDatepicker<D> extends MatDatepickerBase<MatDatepickerControl<D>, D | null, D>

D って何だよ! という気持ちになりますが、あとで説明するので先に Base の方を見てみます。

export abstract class MatDatepickerBase<C extends MatDatepickerControl<D>, S, D = ExtractDateTypeFromSelection<S>> implements OnDestroy, CanColor, OnChanges

さらに C と S が出てきます。 C は上の方で載せた赤枠のエリア、つまりインプットの型になります。 S と D はこの Base の定義にヒントがあり、 ExtractDateTypeFromSelection という条件型から察するに、 S は Selection、 D は Date Type です。Selection って言われても分からんと思われるかもしれませんが、これが選択されている日付(複数/単一)を表す値の型になります。範囲選択だと DateRange<D> 、単一だとただの D というように使い分けることで、全く同じ Base で日付の選択処理ができるようにしています。

最後に D ですが、Date Type といえば普通は JavaScript 標準の Date じゃないのか? と思われるかもしれませんが、実際デフォルトは Date です。「なぜ Date になるのか」を知るためには DateAdapter について知っている必要があります。Datepicker は日付の型を D としておくことで開発者が自由に変更できるようにしてあり、実際に D についての処理をするのが DateAdapter<D> です。 上の方で MatNativeDateModule を説明もなくインポートしていましたが、このモジュールが NativeDateAdapter を提供しており、この定義を見ると DateAdapter<Date> を継承していることが分かります。

export class NativeDateAdapter extends DateAdapter<Date>

これが MatDatepickerBase の constructor にインジェクトされると、 D = Date になります。

constructor( // 一部引数を省略
            @Optional() private _dateAdapter: DateAdapter<D>,
            private _model: MatDateSelectionModel<S, D>)

ちなみに MatMomentDateModule を追加でインストールすると Date の代わりに Moment を使うことができます。

ただのデータではない、MatDateSelectionModel

上で Selection として出てきた DateRange<D> や、Datepicker で モデルとして使われる MatDateSelectionModel は date-selection-model.ts にまとまっています。

export abstract class MatDateSelectionModel<S, D = ExtractDateTypeFromSelection<S>>

この抽象クラスを継承した以下が実際に範囲選択で使われるモデルです。

export class MatRangeDateSelectionModel<D> extends MatDateSelectionModel<DateRange<D>, D>

このモデルがどこからやってくるのかというと、MatDateRangePicker のメタデータを見ると分かります。

@Component({
  // 一部省略
  providers: [MAT_RANGE_DATE_SELECTION_MODEL_PROVIDER]
})

providers で MAT_RANGE_DATE_SELECTION_MODEL_PROVIDER を指定しています。この provider はファクトリーメソッドを持っていて、MatDateRangePicker が作られる際にそのファクトリーメソッドを使ってモデルを生成し、constructor に渡します。

MatDateSelectionModel のコードは割とシンプルですが、ポイントとしては内部に S (Selection、つまり範囲選択の場合はDateDange<D>)を保持していることと、以下のメソッドで外部から値を更新できるようにしていること、

updateSelection(value: S, source: unknown)

そして以下を公開することで他のコンポーネントが値の変更を検知できるようにしていることが挙げられます。

selectionChanged: Observable<DateSelectionModelChange<S>>

モデル、というと単なるデータのようなものを想像したのですが、単なるデータを class でラップしてデータの入出力機能をつけたのが MatDateSelectionModel ということになります。

コンポーネント間の連携の仕組みその1

ここではまず MatDateRangePicker と MatDateRangeInput の連携を見ていきます。上と同じ図を再掲しますが、 mat-date-range-picker と mat-date-range-input を見ると前者が #picker で参照できるようになっていて、それを後者に [rangePicker]="picker" としてセットしています。

結論をいうと正にここで連携をしているのですが、 picker がセットされるとインプットの方で以下のメソッドが呼び出されます。

set rangePicker(rangePicker: MatDateRangePicker<D>) {
 // 一部省略
 this._model = rangePicker._registerInput(this);
 this._rangePicker = rangePicker;
 this._registerModel(this._model!);
}

ピッカーの _registerInput を呼んでいて、その内容はこのようになっています。

_registerInput(input: C): MatDateSelectionModel<S, D> {
  // 一部省略
  this._datepickerInput = input;
  return this._model;
}

要はインプットに対してピッカーがセットされた時に、ピッカーからインプットにモデルの参照を渡すようになっていて、お返しに(?)インプットは自分の参照をピッカーに渡しているイメージです。インプットの _registerModel はさらにその子(具体的には matStartDate と matEndDate)にモデルを渡しています。子の _registerModel では以下のようにモデルの selectionChanged を購読していて、こうすることでモデルのデータに変更があったらインプット側にそれを反映させる、ということができています。

_registerModel(model: MatDateSelectionModel<S, D>): void {
  this._model = model;
  this._valueChangesSubscription.unsubscribe();

  if (this._pendingValue) {
    this._assignValue(this._pendingValue);
  }

  this._valueChangesSubscription = this._model.selectionChanged.subscribe(event => {
    // 省略
  });
}

もう1つ細かいポイントとして _pendingValue が挙げられます。勘のいい方はお気付きかもしれませんが、この _model は最初は undefined です。例えばインプットに初期値がセットされていて、かつモデルがまだセットされていない場合はその初期値の行き場がないので、いったん _pendingValue に入れておき、モデルがきたらそれをモデルに入れて以降はモデルを使う、という仕組みになっています。

コンポーネント間の連携の仕組みその2

次に MatDateRangePicker と MatDatepickerContent の連携ですが、基本的にはピッカーからカレンダーUIを表示する際に連携をします。ちょっと興味深いのは、スマホとPCで別の表示の仕方ができるようにしている点です。 mat-date-range-picker に touchUi というオプションをセットすることで、カレンダーがパネルではなくダイアログで開くようになります。

パネルの場合は CDK の ComponentPortal を使い、ダイアログの場合は Mat Dialog を使っていますが、どちらも表示する内容は MatDatepickerContent (以下、コンテント)です。

ピッカーからコンテントを開く時に _forwardContentValues という以下のようなメソッドを呼んでいて、自分(ピッカー)の参照をコンテント側にセットするなどしています。

protected _forwardContentValues(instance: MatDatepickerContent<DateRange<D>, D>) {
  instance.datepicker = this;  // 継承元の処理
  instance.color = this.color;  // 継承元の処理

  const input = this._datepickerInput;

  if (input) {
    instance.comparisonStart = input.comparisonStart;
    instance.comparisonEnd = input.comparisonEnd;
  }
}

ここでのポイントは、このメソッドでモデルを渡していないことです。では、一体どこでモデルを渡しているのでしょうか? 🤔

例えば MatDialog を普段使うときは、ダイアログを開くメソッドの引数に data を渡す方法でデータを渡すことがあると思います。ではその部分を見てみましょう 👀

this._dialogRef = this._dialog.open<MatDatepickerContent<S, D>>(MatDatepickerContent, {
  direction: this._dir ? this._dir.value : 'ltr',
  viewContainerRef: this._viewContainerRef,
  panelClass: 'mat-datepicker-dialog',
  // 一部省略
});

実際にソースコードを見てもらえば分かりますが、data は出てきません。謎は深まるばかりです…といったところでネタバラしをすると、ポイントはコードのこの部分です:

viewContainerRef: this._viewContainerRef,

詳しくは MatDialogConfig の viewContainerRef オプションの説明を読んでいただくとして、ピッカーからコンテントへモデルを渡す方法はインジェクションです。ピッカーから viewContainerRef を指定してダイアログを表示すると、そのダイアログがピッカーの子になります。そして ElementInjector の機能により、子はインジェクトが必要なものがある場合、親までさかのぼってそれを探します。結果、親であるピッカーにインジェクトされたモデルが子であるコンテントにもインジェクトされる、というのが真相です。

モデルを外から操作するには?

ここまで、モデルがコンポーネント間でどう受け渡しされているのかを見てきましたが、これらを使っている親コンポーネントからモデルを操作したい場合はどうすればいいでしょうか。

最初の方に見た通り、MatDatepickerBase の constructor にモデルがインジェクトされるのですが、private であるため外からモデルを触ることはできません。また protected ではないため継承して中から操作することもできません。

constructor(// 一部省略
            private _model: MatDateSelectionModel<S, D>)

万策尽きた 😩と言いたいところですが、その方法はここまでの説明で既に出てきています。そう、インジェクションです。以下は MatDateRangePicker を使っているコンポーネントでそれをやってみた場合の例です:

@Component({
  selector: 'app-date-range-picker-form',
  templateUrl: './date-range-picker-form.component.html',
  providers: [MAT_RANGE_DATE_SELECTION_MODEL_PROVIDER],
})
export class DateRangePickerFormComponent<D> {
  constructor(
    private model: MatDateSelectionModel<DateRange<D>, D>
  ) {
  }

  // 省略
}

親コンポーネントにモデルをインジェクトしてしまえば、後は何もしなくても ElementInjector が子の MatDateRangePicker に同じものをインジェクトしてくれます。これにより、親コンポーネントも含めて各コンポーネントが同じモデルを参照することになり、親側でもモデルに対して updateSelection を実行したり、 selectionChanged で変更検知をしたりすることができます。

落穂拾い

最後に何点か、コードを読んでいて気付いたことを挙げておきます。

• 日付のフィールドにカーソルを置いて Alt (Mac の場合は Option) + ↓ (下矢印)を押すとカレンダーUIが開きます。実際に処理が定義されているのはこちらです。
• コンポーネントの共通処理をまとめる場合、 @Directive をつけたabstract class として定義して、各@Component の class でそれを継承するのが王道パターンのようです。
• パフォーマンス対策として changeDetection: ChangeDetectionStrategy.OnPush はおそらく必須です。

まとめ

という訳で初めて公式のコードを読んでみたのですが、最初はジェネリック型が何で、どこから出てくるのかよく分からなかったり、やたらとアンダースコアで始まる命名が多かったり、datepicker-base.ts に重要なクラスが複数書かれていて「なぜファイルを分割しないのか…」と思ったり、date / range / picker / input / base のような単語が色々な組み合わせで出てきてどれがどれだか分からなくなったりしましたが、だんだん把握できてくるとおもしろくなってきました。特にインジェクションについては雰囲気でやっているところがあるので、今回改めて調べたことで以前より理解できるようになった気がします。

今後こういったコードを読む時も、ジェネリックな型、 @Component/@Directive とproviders、constructor、viewContainerRef 辺りにまず注目すれば読みやすそう、ということも分かりました。

一方で今回分かったことを普段の開発でも活用できるかというと、ここまできっちりインターフェースを使って疎結合にしたり、ジェネリック型で型を取り替えられるようにしたり、というのはあまりやらないかもしれない、と思います。ただそういうことをしたくなった時のために知っておくのは悪くないのでは、と思います。

それではここまで読んでいただき、ありがとうございました 🙇

Angular 10 の Date Range Picker の裏側 was originally published in nextbeat-engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

自分は普段は Lambda をほとんどさわっていないのですが、せっかくイベントでも話を聞いたので、動画のサムネイル作成をやってみました。といっても、またしても(?)自分でコードを書いた訳ではなく、github にあがっている https://github.com/binoculars/aws-lambda-ffmpeg を使ってみました。あ、ふだんはちゃんとコードを書いています…汗

binoculars/aws-lambda-ffmpeg で何ができるのか

この Lambda は 2 つの S3 バケットを使うのですが、片方の入力用に設定した S3 バケットに特定の拡張子 (mp4など) の動画をアップロードすると、それがトリガーになって Lambda が実行されて、少し待つともう1つの S3 バケットにリサイズされた動画とサムネイルの2つが作られます。

変換後の動画やサムネイル画像の形式、最大幅は設定ファイルで指定できますが、例えば1つのバケットで完結させたいとか、今回の記事のようにサムネイル画像だけ生成したい場合は少しコードの方をいじる必要があります。それはこの記事の後半で触れることにして、まずはそのまま使う方法を説明していきます。

リポジトリの具体的な内容

このリポジトリの内容ですが、Lambda の言語は node.js が使われています。具体的にはこの node.js を作った Lambda 用のファイル一式をビルドして、AWS 環境にデプロイしてくれる gulp のコマンドが入っています。

コマンドが具体的にどんなことをやってくれるかというと、まず動画サムネイル作成用の ffmpeg をダウンロードして、それから設定ファイルを元に Lambda 用のビルドを行って、それを S3 にアップロードしてくれます。それから CloudFormation を使って、動画のアップロード先や Lambda の実行ファイルの置き場所に使うなど、目的ごとの S3 バケットを作成したり、権限や Lambda の設定をやってくれます。

基本的にはコマンドを叩けばすぐに環境ができあがるようになっています。なお一度デプロイしたあとでコードだけ更新する用のコマンドもちゃんとあります。コマンドのコードはルートの gulpfile.js と、platform/aws/gulpfile.js に書かれています。

準備

基本的にはコマンド 1 発! のはずなのですが、いくつか準備が必要で、やっていなかった自分は何回かやり直すはめになりました…。

binoculars/aws-lambda-ffmpeg

セットアップについては上のリンク先に書いてあるのですが、若干分かりづらいので補足すると、 4 で Lambda のファイルを置く用のバケットを指定します。あらかじめ作っておきます。

5 では config/aws.json の編集をします。変更必須なのはこのへんです。

• functionBucket: 4 のバケット
• sourceBucket: 動画をアップロードするためのバケット。このバケットはあとで CloudFormation で作るので自分で作らない。作ると CloudFormation の実行でエラーになる。
• destinationBucket: リサイズされた動画とサムネイル画像が作られるバケット。CloudFormation で作るので事前に作っちゃだめ。sourceBucket と同じもだめ。なぜかというと sourceBucket でのファイル生成をトリガに Lambda を実行するので、Lambda によって sourceBucket にファイルが生成されたらまた Lambda が呼ばれてしまうため。

7 の前にもいくつかやることがあって、まずはいつもの環境変数の設定です。ここの export を各自の値にして実行します(nvm 以下はもちろん関係ないのでやらなくていいです)。

binoculars/aws-lambda-ffmpeg

7 の前にやらないといけないもう 1 つ大事なことが実行用のユーザに権限ポリシーをちゃんと設定しておくことです。本当は細かく設定すべきだとは思いますが、とりあえずこれを付与しました。

• AWSLambdaFullAccess
• AmazonS3FullAccess

また CloudFormation の権限は “Create User Policy” の “Policy Generator” から設定する必要があります。以下を設定します。

• CreateStack
• UpdateStack
• DescribeStackResource

ここまでできたら gulp aws:default を叩けば待っているだけで全ての設定が完了します。コマンドが終わったらマネジメントコンソールで CloudFormation を見にいきます。ここでスタック作成が完了したら実際に Lambda を試せます。

画像が地味ですが、こんな風に SourceBucket に動画をアップロードすると

DestinationBucket にリサイズされた動画とサムネイル画像が作られます。

改造してみる

これで終わるのも何なので、ちょっと改造してみました。やったこととしては、動画の方は作らずに、サムネイル画像だけ作るようにして、かつ動画をあげたバケットと同じ場所に作られるようにしました。
変更が必要なのはこの辺のファイルです:

• config/aws.json
• platform/aws/cloudformation.json
• platform/common.js

config/aws.json

destinationBucket は sourceBucket と同じ値にします。ちなみに上で既にスタックを作っていた場合は、バケット名は別のものにしないとデプロイ時に「もうあるよ!」と怒られます。どうしても同じにしたければ、バケットの中身を全て消したあとでスタック自体を消します。

また format の中の video を消しておきます。残しておくとサムネイル画像しか作らないのに動画も S3 にあげようとしてエラーになります。image の方は JPEG にしたかったので extension = jpg、 mimeType=image/jpeg にしました。

platform/aws/cloudformation.json

Resources の DestinationBucket は不要なので消します。

Resources > SourceBucket > Properties > NotificationConfiguration > LambdaConfigurations の Event のあとに以下を追加します。同じバケットにサムネイル画像を作るとまた Lambda が実行されるので、ファイル名の後ろに .mp4 がつくものをあげた時だけ実行します。ただこの回避策だと当然 mp4 以外の動画が使えません(汗)が今回はこれでよしとします。

 “Filter”: {“S3Key”: {“Rules”: [{“Name”: “Suffix”, “Value”: “.mp4”}]}},

platform/common.js

ffmpeg 関数の中をいじれば OK です。description はいらないので消すのと、あとは ffmpeg の動画出力に関わるオプションを消します。

デプロイ

変更できたら gulp で aws:default を実行します。バケットに動画をあげると今度は同じ場所に画像が作成されます。

注意

間違ってビルドで作られたファイルの方(dist 以下)を変更すると、gulp でコマンドを実行した時に元の内容で上書きされて悲しい気持ちになるので気をつけましょう。。厄介なのはデプロイして初めて気付くことです。

Lambda が実行されてなさそうだったら、Lambda のページに CloudWatch のログへのリンクがあるのでそこからログを読んで原因を調べます。コードの変更だけなら aws:update で更新できます。

Lambda についてはリクエスト数など無料で使える範囲があるので、その点で手軽に試せていいなと思いました。CloudFormation に慣れていなかったのでそこで多少つまづきましたが、他人のライブラリを使ってかなり手軽に動画のサムネイル生成ができました。あと ffmpeg は普通にやるとインストールが結構面倒なんですけど、バイナリ配られてたんですね。。こういう小さくまとまった処理を、サーバーなしで使いたい場面でやはり Lambda は向いているなと思いました。

AWS Lambda で S3 の動画のサムネイルを作る was originally published in Castalian’s Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

最近、LINE や Facebook の Bot の API が試せるようになっているので、自分でも Facebook の方を試してみました。なお公式のチュートリアルはこちらです:

Getting Started - Messenger Platform - Documentation - Facebook for Developers

使ったもの

基本的にほとんど自分でコードを書いた訳ではなくて組み合わせて動かしただけなので、タイトルも「動かしてみた」にしています。使ったものはこちらです：

• AWS API Gateway: HTTPS が必要だったので Proxy のためだけに利用
• AWS EC2: Python の Flask アプリを動かすために利用。上のGatewayでこのサーバにプロキシします
• Python の pymessenger ライブラリ: Bot API のラッパー。サンプルにエコー Bot の Flask アプリが入っているのでこれを少し書き換えて使います

必要なもの

必要なものはこちらです：

• Facebook のアカウント
• AWS のアカウント
• Slack の Custom Integrations の Incoming WebHooks の Webhook URL

以下、簡単な手順です。

1. Facebook のデベロッパーサイトでアプリとページを用意してページアクセストークンを取得

Bot を試すためには Facebook アプリの機能の1つとして送受信API を有効にすればいいだけなので、既存のアプリがあればそれを使ってもいいし、なければ普通にアプリを1つ追加します。

既存のアプリだろうと新規アプリだろうとやらなければいけないのはサイドバーの Messenger から Messengerプラットフォームの「スタート」をクリックすることです。

その後トークン作成のパネルで Facebook ページを作成してトークンを取得します。

次に Webhooks のセットアップに進みたいところですが、実際に Bot が動いていなければセットアップできないので、このページでの設定作業はここまでいったん終わりです。

2. EC2 のインスタンスを起ち上げて Bot を動かす

とりあえず t2.micro あたりのお金のかからないインスタンスを起ち上げます。OS は Amazon Linux にしておきました。Public IPさえあれば特に必要な設定はありません。セキュリティグループは作業用の SSH と API 用のポート(適当なポートでOK)を受け付けていれば問題ないです。

EC2 インスタンスに SSH でログインしたら Python3 と virtualenv をいれておきます。

sudo yum -y install python34 python-virtualenv

Bot 用の Python の環境を作って必要なライブラリをインストールします。

virtualenv -p python3 myvenv
source ./myvenv/bin/activate
pip install flask pymessenger slackweb

Bot のスクリプトは以下を書き換えて使います。Git を入れて clone してもいいですが、動かすだけならこのファイルだけでかまいません。

davidchua/pymessenger

書き換えた後のスクリプトは左のようになります。

9行目の TOKEN のところに 1 で取得したトークンを入れます。

13行目には Slack の Webhook URL を入れます。

18行目の “0123456789” は自分で好きな文字列をいれます。URLに入れるので半角スペースなどは避けておくのが無難です。あとで Facebook の設定画面等で使うので覚えておきます。

起動します。

nohup python messengerbot.py > $HOME/out.log 2> $HOME/err.log < /dev/null &

試しにアクセスしてみます。verify_token は上の18行目に入れたものを使います。”works” が返ってきたら成功です。SSH を抜けて API Gateway の設定に移ります。

curl "localhost:5002/webhook?hub.verify_token=0123456789&hub.challenge=works"

3. API Gateway で EC2 にプロキシする

Create API で API を追加したら、メソッドを2つ追加します。

• Integration type: HTTP Proxy
• HTTP method: GET と POST (ここだけ違うものをそれぞれ作ります)
• Endpoint URL: http://[EC2 インスタンスの Public IP]:5002/webhook

GET Method の方は、URL Query String Parameters に以下を追加しておきます。

• hub.verify_token
• hub.challenge

設定ができたら、Actions から Deploy API でデプロイします。Stage の名前は “beta” にしておきます。

デプロイがうまくいったら URL が表示されます。ブラウザから試しにアクセスしてみて、”works” が返ってきたら成功です。

https://**********.execute-api.**************.amazonaws.com/beta/?hub.verify_token=0123456789&hub.challenge=works

4. FBアプリの送受信API Webhooks の設定

手順の 1 のページで Webhooks の設定をします。

• コールバックURL: https://**********.execute-api.**************.amazonaws.com/beta/
• トークンを確認: 0123456789
• フォロー入力欄: とりあえず全部チェック

設定できたら、公式チュートリアルにある通り以下のコマンドを叩いておきます。

curl -ik -X POST "https://graph.facebook.com/v2.6/me/subscribed_apps?access_token=<FBページのトークン>"

5. 動作テスト

ここまでできたら、Bot 用に作成した FB ページのメッセージから Bot のテストができます。何かメッセージを書き込むと Slack にそのメッセージが表示されます。他の人も書いていますが、あまり反応の速度は速くないです。

以上、Messenger の Bot を試してみる簡単な手順でした。お疲れさまでした!

Amazon API Gateway は LINE Bot API に関するブログ記事で便利そうだったので初めて使ってみましたが、毎回違うIPからプロキシ先にアクセスしてくるあたりは使い方を気をつける必要がありそうです。

なお今回作成した Bot は特に実用性がないのですが(汗)、Facebook の Bot の機能には他にもユーザーに選択肢を表示するといったものがあるようですので、それらを試してみるとっかかりとしては手軽でいいかなと思いました。(おしまい)

話しかけられた内容をそのまま Slack に流す Facebook Bot を Python で動かしてみた was originally published in Castalian’s Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

コードレビューは、正直あまり楽しくない作業です。

簡単なものや、量が少ないものはそんなに苦ではありませんが、複雑なものや、別のプロセスと連携するものなど、正直コードを読んでもよく分からない、ということがよくあります。

今回はコードレビューを自分がどう捉えているのか、そしてどんな風にやっているのか、について書きます。

どこを見るのか?：自分の場合

基本的には、自分は「バグを見つけること」に重点を置いています。

もちろん「もっと単純に書けるところを探す」「もっと速い処理に書き換えられそうなところを探す」「設計がまずいところを探す」「誤字を見つける」「コメントの間違いを見つける」「何をやっているのか分からないところについて質問する」などコードレビューでできることは色々ありますが、自分は究極的にはバグやエラーになるところをできるだけ探すようにしています。

動かない綺麗なコードより、動く多少汚ないコードの方がましだと思っているためです。どんなに綺麗なコードを書いたところで、使えなければ意味がないです。

コードは読まない

正直なところ、自分はそんなにちゃんとコードを見ません。

むしろ動かしてまず、今回の機能で新たにできるようにならないといけないことがちゃんとできるか、を確認します(逆にいうと何ができるようになるのか仕様が理解しづらいものほどレビューしにくいものはありません)。

それから入力等でできるだけおかしい入力や操作をしたり、データをほぼ空の状態にしてエラーになったりしないかを確認します(データが少ない時のチェックは、開発した本人は色んなテストデータを入れた状態で開発している分、忘れがちです)。

それコードレビューじゃないのでは

確かにそうです。正確にはコードを見つつ動作確認しているだけです。ただこの「コードレビュー」なら、割と誰でもできます。

本当は設計などのもうちょっとレベルの高いところの話をすべき場なのかもしれないですが、その辺りは自分の担当の範囲でいいと思う設計やいい書き方を心がけて、他の人がレビューした時に参考になることを目指す、という感じでもまあいいんじゃないかと思います。

「なぜこういう作りにすべきなのか」を説明しようとしても、将来その部分を変更することになった時でないと理解しづらいことが多いと思います。

全部のバグを見つけられるのか

はっきりいって不可能だと思います。

でも「どうせできないからやらない」よりも、「できなくてもやらないよりはまし」という気持ちでやっています。

自分がレビューした結果、まずいところを全部見つけられなかったとしても、全くやらなかったよりはましだ、と考えます。大抵のコードは、書いた本人以外が1度見るだけでも、意外と本人が気づいていないことが見つかるものです。

逆にいえば、そういう理由から必ずコードレビューをすべきです。努力目標ではなく、必須です。片手間の時間つぶしではなく、開発と同じくらい重要なタスクです。エンジニア以外の人にもこのことはよく理解してほしいです。

こんなスタンスになった訳

元々働いていたソーシャルゲームの会社で、毎日、時には1日に数回リリース作業があったためです。

こんな速いペースでリリースを繰り返していたのでは、コードレビューの時間が十分にとれません。大量の差分を1時間以内に確認しなければいけないこともありました。

その時に思ったのが、「例え全部確認できなくても、全くやらないよりはやるべきだ」ということでした。余談ですが、1時間以内にレビューした時は普通にバグが出て、結構大変なことになりました。でも、やったことを無駄だとは思っていません。やっていなかったら、もっとひどいことになっていたかもしれないからです。

コードをあまり読まずにコードレビューがしたいあなたへ

• テストカバレッジが手元にあるなら、差分を見ながらカバーされていないところだけ読む、あるいはそこを通るように操作してみる。大抵クリティカルなバグはないけどちょっとしたバグは見つけやすい
• JS がらみの変更は少なくともChromeの開発ツール等でエラーメッセージが出ていないか確認する
• PyCharm などの JetBrains の IDE だったら、レビュー対象のコミットをログの画面から全部選択すると変更のあったファイルのリストが表示されるので、それを全部選択して「Inspect Code…」を実行する。些細なミスを見つけやすい
• HTML を大幅に変更していたらブラウザ上の HTML をHTMLバリデーターにかけて問題ないか確認
• MySQL であれば、DBを大幅に更新するようなバッチコマンドのレビューだったら mysqldbcompare で差分確認
• とりあえず連打 & 同じ操作を連続でやる & バッチコマンドは2回叩く
• とりあえずウインドウリサイズ
• ログアウトして同じURLを叩く
• 想定されているフォーマット以外のものを送信 & 入力する
• とりあえず全部空で送信する
• Webのフロントエンドの変更だったら普段使っていないブラウザで見る
• 変更された部分と似たような画面や機能を確認。同様に変更しないといけなかったり、あるいは影響してはいけないのにしてしまっていることがある
• 名称の変更があったらとりあえず変更前の単語でgrep検索。変更漏れがあるかもしれないので
• とりあえずコメントは疑っておく
• 誤字が多い場合、大抵バグがあるのでその周辺をよく見る
• CIで実行されないテストは大体怪しい
• 本当に時間がないなら、その機能を使う一番単純なフローを実行して問題ないか確認する

最後に：コードレビューは愛である。たぶんね

それでもバグが起きてしまった場合、おそらく一番責められるのはそれを書いたプログラマです。

レビューした人も、できるのにレビューしなかった人も、動作テストした人も、できるのに動作テストしなかった人も、書いたプログラマほどは責められないと思います(ここは異論ありそうですが)。

なおここで「しなかった人」を挙げているのはもちろん、その人にも責任があると思っているからです。

そうならないようにするのが、自分にとってのコードレビューです。誰かにバグを出してほしくないからレビューします。バグが出ればもちろんユーザが困るし、本人だけでなく他の人も対応に時間を取られます。だからこそ、バグが出ると思われる箇所はしつこく指摘します。

一方で、レビューや動作検証で事前に防ぐことができたバグ、生まれる前に消し去られたバグのことは、関わっていない人は誰も知らないし、特に評価もされません。

まあそういう訳で(?)、プログラマにとって、コードレビューしてくれる人がいるっていうのは結構幸せなことなのです。

コードレビューは愛である was originally published in Castalian’s Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.