はてなブックマーク

gRPC関連でprotocol buffersを使うことが増えたのだが、protocol buffers自体にまだ慣れていないので調べてまとめる。 https://developers.google.com/protocol-buffers/docs/proto3 protocol buffers自体のおさらい Googleが2008年にOSS化したプログラミング言語に中立なデータのシリアライズ形式である。(略称はprotobuf) 型情報は.protoというIDLに書き、これを送信と受信の双方で事前共有しておく。こうすることによって余計な型情報を省いてバイナリに固めることができる。 この性質から、APIドキュメントとしても使える。「RESTっぽいJSON API + OpenAPIによる記述」とだいたい同じニーズをカバーする。(IDLを抜きにしてMessagePackやJSONと比較する

必要に迫られて、Goでバイナリの読み書きをしているのですが、encoding/binaryに関する解説が少ない気がしたのでまとめます。 固定長フォーマットとは なんかこう、「先頭から 4byte, 2byte, 10byteという風に区切って、最初の4byteがA, 次の2byteはビッグエンディアンでuint32扱いでB, 次の10byteは文字列…」みたいに、一切の説明が省かれたフォーマットのことを指して発言しています。 当然、元データをparseして、構造体とかに変換してからプログラムで扱いたくなると思います。ただの[]byteのまま扱うとか地獄すぎですよね。 // 実行イメージ func TestParseBinary(t *testing.T) { b := []byte{ 0x12, 0x34, 0x56, 0x78, // この辺はAの領域 0x12, 0x34, 0x56,

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

だいぶ昔の記事ですが、 Golang Error Handling lesson by Rob Pike - Block Rockin’ Codes の、自分なりの理解をメモします。 if err != nil { ... }が多すぎるコード Goは例外機構がありませんので、戻り値を使ってエラーを伝搬していく必要があります。 func doSomething() error { resA, err := doA() if err != nil { return err } resB, err := doB(resA) if err != nil { return err } resC, err := doC(resB) if err != nil { return err } err := doD(resC) if err != nil { return err } } もちろんこれは擬似

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

やっぱり自分なりにまとめないと理解した気になれないので、まとめてみることにする。 https://godoc.org/github.com/pkg/errors Golangにおけるエラー処理(おさらい) Goは言語仕様として例外機構(Exception)がない。例外ではなく、複数の戻り値を返せるという特徴を利用し、最後の戻り値をエラーに割り当てるということをする。throwを書きたくなったら代わりにreturnを書くわけだ。 import "fmt" // helloはnameが空だったらエラー扱いにする func hello(name string) (string, error) { if name == "" { return nil, fmt.Errorf("name is invalid") } return fmt.Sprint("hello %v", name) }

declare(strict_types=1); とは、PHP7から導入された、厳格な型検査モードの指定構文です。 有効範囲をあまり把握してなかったのでまとめてみました。 strict_types基本の動き 例えばこんなコード。 <?php function add(int $a, int $b): int { return $a + $b; } var_dump(add(1.0, 2.0)); この状態で単体実行すると、int(3)が出力されます。 渡しているのはdouble型なのですが、よしなにキャストされて処理されています。まあ、昔ながらのPHPらしい動きです。 ここで、declare(strict_types=1)を有効にしてみます。

タスクの工数を見積もる際に、タスク自体が確定していないから、見積もりにくいことがあります。 こういう時、その不確定さも含めて見積もってしまい、作業バッファとして積むという技があります。(勝手に2点見積もりと呼んでいます) 少しまとめておきます。 ちなみに、見積もりの単位はストーリーポイントでも人日でも関係なく使える話です。 平均時間と最悪時間 勘でタスクごとに2つの見積もり数字を出します。 「平均的に終わらせるとしたら」の時間 「ハマったりして時間がかかったとしたら」の時間 なお、(2)は「明日、地球に隕石が落下して世界が滅びたらどうしよう」みたいな、常識的に考えると起こり得ないことまでは考慮しません。想定できる範囲で、「悪いことが重なったらどうしよう」と考えてください。 イメージとして、50%と90%を念頭においてください。 50% ぐらい、もしかしたらオーバーするかも 90% まあ確実

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

(例外安全ネタでもう少し長い記事が書きたいんだけど、思いつきだけまとめておく) PHPにはアトミックでない関数が結構ある。本来1つの処理だったものが複数に分かれているような関数。終了する方の関数を呼ばずにいると、変な状態のままになってしまう。 fopen/fclose flock(LOCK_EX)/flock(LOCK_UN) PDO::beginTransaction / PDO::commit / PDO::rollback ob_start / ob_get_clean こういったものは気をつけて書かないと終了の関数だけが実行されず、例外安全を破ってしまう。 どうすれば「気をつけて書いている」ことになるのか考えてみた。 finallyを都度書く finallyを使えば、例外が起きても終了処理が呼ばれる。とりあえず、これで例外安全にはなる。

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

PHPのHTTPクライアントライブラリであるところのGuzzleは、実際にHTTPリクエストを行う部分をハンドラと称して切り離せるようにしており、ここを差し替えることでモックを作ることができます。 テストのときに実際のAPIサーバーへリクエストを投げなくても、思った通りのレスポンスを受け取ったことにして、コードを実行することができます。 Guzzle公式のMockHandler Guzzleには標準でMockHandlerなるテスト用のハンドラが付属します。 http://docs.guzzlephp.org/en/latest/testing.html#mock-handler use GuzzleHttp\Client; use GuzzleHttp\Handler\MockHandler; use GuzzleHttp\HandlerStack; use GuzzleHttp\Psr

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

PHPのSPL系組み込み例外は全部で13個あるんですが、正直、使い分けがよく分かりませんでした。公式ヘルプを見ても、わかったような、わからんような。。 (全部うしろにExceptionって付くので省略してます) Logic系 BadFunctionCall BadMethodCall Domain InvalidArgument Length OutOfRange Runtime系 OutOfBounds Overflow Underflow Range UnexpectedValue 名前の似ているOutOfRangeとOutOfBoundsが全然違うって辺りが罠。 どういうときに使われるのかをPHP本体のソースコードからgrepしてみます。 そもそも、SPLというオブジェクト指向のライブラリを作る上で導入されたのがSPLの例外だったはずだから、本家の使い分けが一番信用に足るはず。。 ソ

すげー便利そうに見えて、微妙に使いづらい子だな…という印象。(言いたいこと終わり) https://phpunit.de/manual/current/ja/appendixes.assertions.html 配列のアサーションの問題 例えば、ある関数の実行結果がこういう感じの配列をだとしよう。 [ [ 'name' => 'taro', 'gender' => 'male', 'updated' => '2015-08-10 12:01:13', ], [ 'name' => 'hanako', 'gender' => 'female', 'updated' => '2016-07-31 13:04:14', ], ]; 関数のテストを書くなら、↑の配列をexpectとして用意して、結果をassertEqualsで比較すればいい。 ところが、別に全部の要素を厳密に比較しなくてもいいこと

意外と知られていないような気がしたので。 普通にタイプヒントを書くと、nullを許可しない設定になる。

final や public の順番は、ひっくり返しても別に動作するのだけど、なんとなく順番を決めたほうが気持ちが良いもの。調べてたらPHPとJavaで作法が違ったのでメモ。 PSR-2が実質上の標準。 http://www.php-fig.org/psr/psr-2/ Visibility MUST be declared on all properties and methods; abstract and final MUST be declared before the visibility; static MUST be declared after the visibility. abstract / final (あれば) visibility (private / protected / public) 常に書く static (あれば) PHPは他に修飾子がないので、3つ

composer-pluginの一種なんだけど、ちょっと面白いなと思った。 インストール(グローバルでもいいし、パッケージローカルでもOK)すると、composerのサブコマンドに、qa:から始まるものが色々生える。 webysther/composer-plugin-qa 自体は、特に何かをrequireしているわけではなく、このサブコマンドを生やすという機能単体で実装されている。 composer qa:testがPHPUnitに対応していて、ローカルにインストールされた vendor/bin/phpunit と同等の意味になる。 他にもphpcbf, phpcsなどのツールも、composerのサブコマンドから叩ける用にしてくれる。 vendor/bin/phpunitの代替手段 - Qiita scriptsで頑張ってcomposer testなどのサブコマンドを生やしている人も多

PHPUnitのデータプロバイダという機能について、自分なりにまとめます。 データプロバイダとは何か PHPUnitで、複数のテストパターンを書くことはよくあります。この時、似たようなアサーションを何度も書くことになります。 例えば… 足し算するだけの関数をテストするとして、

<?php define('HOGE', 'hoge'); const FUGA = 'fuga'; 見て分かる通り、defineは関数であるのに対しconstは関数ではないのでconstの方が高速に処理される。 大量に定数定義したいならconstを使う方が望ましい。 その昔「定数定義を高速に行う」というためだけの関数がいくつか存在していたが、いずれも拡張モジュールのメンテナンスが止まっているようなので、今やるならconst書き換えが現実的なチューニング法なんじゃないかな。 http://php.net/manual/ja/function.apc-define-constants.php https://pecl.php.net/package/hidef defineでしかできないこと defineは関数なので、引数には式であれば何でも書くことができる。関数の実行結果を書いてもOK。

Prophecyとは phpspec/prophecy PHPUnitと組み合わせて使えるモックライブラリ。 元はphpspecの一部として開発されたもので、phpspecと組み合わせなくても単独で使うことができる。 PHPUnit 4.5からパッケージに同梱されるようになった。PHPUnitの新しいバージョンを使っていれば、composer.jsonに加えなくても使うことができる。 テストダブルとは ユニットテストを書くときに、テスト対象の依存の代替として使うオブジェクトをテストダブルと言う。目的はいくつかある。 依存オブジェクトの準備を手抜きする。100行の準備をしないとテストが書けないとしたらユニットテストが読みにくくなってしまう。 実行しづらいメソッドを差し替える。外部へ通信してしまうもの、I/Oが発生するもの、すごーくたまにしか失敗しないものなどを強制的に変更したいとき。 メソッ

しかしコマンドが長くなるし、イマイチ格好良くない。 そもそも、vendor/binはcomposerの設定によって変更可能であり、ハードコードするのも行儀が悪い。 $(composer config bin-dir)/phpunit vendor/binのハードコードをなくすとしたら、こう書ける。しかし大変ダサい…。vendor/binよりもタイプ数増えてるし。

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

.phpdbginitという名前のファイルをカレントディレクトリに置いておくと、phpdbg起動時に読み取って勝手に設定してくれる。 ブレークポイントの設定 (break 関数名)などを書くのが定番だけど、関数を作ってregisterしておくこともできて、適当にbtっていうスタックトレースを表示する関数を作ってみた。 こんな風に <: 〜 :>でくくった部分はPHPとして実行され、関数の登録ができる。 <: function bt() { $bt = debug_backtrace(); foreach ($bt as $i => $trace) { echo "$i => "; if (isset($trace['class'])) { echo "\033[36m$trace[class]\033[m$trace[type]"; } echo "\033[32m$trace[funct

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Composerのリポジトリは簡単な認証であれば設定できるようになっている。基本的に$(composer config -g cache-dir)/auth.jsonに記載していくが、configコマンドでも設定が可能。 すべてドメインごとに設定できる。 Basic認証 なんかconfigコマンドに渡すhttp-basic.という部分がドメインの一部っぽく見えるが関係なくて、http-basic.まではJSON記法、それ以降がドメインを指す。(http-basic[example.com]みたいな記法だったら分かりやすかったのに。。) たとえばexample.comに対してユーザー名：aribaba パスワード：opensesameが必要だったとしたらこんな感じ。