HYBRID発売されましたね。私は間が悪くHHKB追加購入したばかりなので泣いています。id:kfly8です。2019の20日目の記事です。伝えたいことはタイトル通り「フィードフォワードをしてから、フィードバックする」ことが良いという話です。場面はピープルマネジメントを想定していますが、コードレビューがフィードバックの1つなのでエンジニアにとって身近な内容だとも思います。ここでのフィードバックは、目標達成のための軌道修正のことです。ロケットの軌道修正から来た言葉だそうです。ロケット機内にいることを想像してみると、何の手助けなしに自分がどこを飛んでいるのか把握するのは難しいと思います。プログラミングであれば、自分が書いたコードを客観的に見るのは難しいと感じませんか?少なくとも自分には難しいです。コードを一晩寝かせたり、あるいは人に見てもらうことで気づきを得ようとします。自分がロケット機内にいたら問題に気づけないので、ロケットの外に出たり、周りに教えてもらって、ようやくどこにいてどこに向かっているか認識できます。自己認識を調整するために、フィードバックは必要だと思います。対人間のフィードバックでおこりがちな失敗はあると思います。自分は失敗だらけです。フィードバックされる側からしたら「なんでそんなこと言われなきゃいけないんだ」と抵抗を感じることはあるあるです。原因は、フィードバックを求めていない場面だったり、そもそも目標の認識が合わせられてないってことがあると思います。フィードバックが、自分では変えようがない過去の出来事に対しての指摘になるので、批判的なニュアンスがどうしても伴います。フィードバックは、自己認識の調整のために必要だと思いますが、どうしても抵抗感を作りやすい側面があります。フィードバックの抵抗感を緩和する手段はないか?今回の自分の提案は「フィードフォワードしてから、フィードバックする」ことです。フィードフォワードとは、これから起こる出来事を予測し、予告することです。開発をする際、性能か、堅さか、はたまたさくっと書くことか、期待を話し合っておけば、あとでコードレビューする際、どんな観点でのレビューになるのか予想がついていてある程度開発をする人は準備をしているので、抵抗感は減ると思います。準備の期待の合わせだけなく、仕事を進めている最中も「次はこんなこと起きそうだねー。あそこが落とし穴になりそう。」といった話が、「あそこどうだった?」とフィードバック時の伏線に繋がります。まとめると、フィードフォワードとフィードバックの関係を業務に当てはめると次のようなイメージです*1。フィードバックだけの片割れ運用をしていたら、フィードフォワードを意識して取り入れてみると良さそうです。metacpan.orgSub::Metaは、関数の名前、関数の入出力といったメタ情報を扱うためのモジュールです。Sub::Identify,Sub::Util,Sub::Infoといった類似モジュールはありますが、関数の入出力のメタ情報を扱えないためSub::Metaを書きました。基本的な使い方は次の通りです。コードリファレンスを元にメタ情報を抽出できます。['method']コードリファレンス渡すことなく、メタ情報を扱うこともできます。foo関数の入出力のメタ情報を付加できます。'Int'関数の入出力のメタ情報を扱う動機をもう少し掘り下げて、説明します。Smart::Args,Function::Parameters,Type::Paramsなど数多くあります。モジュールごとに使い勝手が異なり、それは多少ストレスだと思いました。型アノテートしているので、静的解析したいと思いました。そのために、関数の入力のメタ情報を取り扱うオブジェクトがあれば、統一されたI/Fで取り扱いしやすくなるのではないかと考えました。関数の出力についても同様です。拙作のFunction::InterfaceといったPerl5でJavaのようなInterfaceを表現しようとした時に、関数の入出力が取り回ししやすいと便利です。現状のF::IはFunction::Parameters,Function::Returnの実装にべたつき、多くの利用用途に対応できず柔軟性に欠けると考えました。ちなむと吉祥寺.pmのフィードバックはこちらです。弊社で吉祥寺pmのフィードバックがあり、懇親会はご飯が旨くて楽しいってフィードバックがされました。https://t.co/7rVLyAjFu2ビール🍺が飲みたくなりました。本題Perlのインタフェース実装をしました。雰囲気はJavaとかのインタフェースです。次のキャプチャにあるように、コンパイル時に色々教えてくれて嬉しいです。使い方まず、インタフェースの定義は次のようにします。$msg、返り値の型はStrな関数helloを宣言します。:Return(Int);}次に、インタフェースの実装は次のようにします。Function::ParametersとFunction::Returnを用いて関数の実装をします。}}そして、ImplOf['IFoo']のようにインタフェースの型指定します。実装に依存しなくなって、嬉しいですね。$foo_service->greet($foo);奇妙ですが、面白いですね!仕組み簡単ですが、次のような感じです。文法を拡張しています。Deparseすると、抽象関数のメタ情報を保存していることがわかります。保存したインタフェースのメタ情報と、Function::Parameters、Function::Returnを用いて取得できる実装のメタ情報を付き合わせて、エラー判定しています。Type::Tinyでparameterizeして型を定義しています。Perlの自由さが感じられて楽しいですね。機会があれば、詳解したいです。さいごに遊んでくれる人がいると嬉しいです。2018の10日目の記事です。JSONをdecodeする時、例えば、123、"123"は型に厳しい言語であれば、別々に扱いたいものです。Perlでぼやっとencodeすると、これらをいっしょくたにしてしまいます。次のコードは123とencodeされることを期待しても、"123"とencodeします。これは、123のperl内部の値のフラグが意図せず、文字列になり*1、encodeされてしまったからです。用いて、期待する型を定義し、encodeする方法について紹介します。型指定をしてencodeする例を示します。}という型指定をし、値を"123"という文字列でなく123という数値にencodeしています。}encode_jsonの第二引数に型を指定しなければ、従来のencodeを行うので取り入れやすいのではないかと思います。nullの4種で、また構造を表現するため、配列、ハッシュがあります。いうsuffixを付けます。配列、ハッシュは、[],{}というリテラル表現か、json_type_arrayof、json_type_hashofといった関数を用います。詳細は、ドキュメントを確認ください。このようなデータをencodeする例を考えてみます。'handleMessage'};この場合、型は次のように定義できます。見たままの型定義で、特に理解に支障はないと思います。JSON_TYPE_STRING,};この型を指定し、encodeすると次のようになります。いった中間表現を用意し、encode/decodeするコードを利用言語ごとに自動生成するアプローチで、言語間の境界を意識する経験をした人もいるかもしれません。第52回「Perlで堅牢な開発」を書かせていただきました。技術評論社の稲尾さん、監修いただいた牧さん、応援してくれたモバファクの同僚、そして家族に協力してもらい、執筆することができました。本当にありがとうございました。Perlでの構文チェックや型制約の活用方法などをいくらかまとめることができたのかなと思っています。お役に立てれば幸いです。ついて紹介したいと思います。よる、Dancer2の超速紹介です。要点が凝縮されたLTです。X目を凝らすとこんなスライドが見えます。DSLで、ルーティングを記述します。返却するようなAPIも簡単に用意できます。Plack化されているので、plackupできます。app.psgiここまでが、LTの抜粋です。そのままに、設計面での調整が大幅に入っています*1例えば、以下のような対応が行われています。(超訳ですが)「全部書き換えるぞい」という記事があります。Calendar利用者が多数のプロダクトにおいて、こういった完全な書き換えは、個人的な興味をそそりました。カンファレンスも開かれています。blog.sukria.net最近の開発状況の話。特徴を触れて、記事を終わりにしたいと思います。Calendarfatpack、つまり一枚スクリプトにするのをサポートしています。扱いです)ポータビリティを考えると良い選択になるかもしれません。Calendarコマンドラインで利用も考慮されています。Calendar複数のアプリケーションの同居が考慮されています。