サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
WWDC25
qiita.com/Hiraku
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? HTTPのステータスコードにあたる概念がgRPC Codeであり、以下で定義されている。 https://github.com/googleapis/googleapis/blob/master/google/rpc/code.proto 例えばGo言語だと以下にprotoから生成されたコードがある。 https://github.com/grpc/grpc-go/blob/master/codes/codes.go 一覧 適当に翻訳していく。 OK = 0 エラーなし。成功を返した。 HTTPだと 200 OK CANCELLED =
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,
qiita.com
やっぱり自分なりにまとめないと理解した気になれないので、まとめてみることにする。 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) }
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? タスクの工数を見積もる際に、タスク自体が確定していないから、見積もりにくいことがあります。 こういう時、その不確定さも含めて見積もってしまい、作業バッファとして積むという技があります。(勝手に2点見積もりと呼んでいます) 少しまとめておきます。 ちなみに、見積もりの単位はストーリーポイントでも人日でも関係なく使える話です。 平均時間と最悪時間 勘でタスクごとに2つの見積もり数字を出します。 「平均的に終わらせるとしたら」の時間 「ハマったりして時間がかかったとしたら」の時間 なお、(2)は「明日、地球に隕石が落下して世界が滅びたらどうし
(例外安全ネタでもう少し長い記事が書きたいんだけど、思いつきだけまとめておく) PHPにはアトミックでない関数が結構ある。本来1つの処理だったものが複数に分かれているような関数。終了する方の関数を呼ばずにいると、変な状態のままになってしまう。 fopen/fclose flock(LOCK_EX)/flock(LOCK_UN) PDO::beginTransaction / PDO::commit / PDO::rollback ob_start / ob_get_clean こういったものは気をつけて書かないと終了の関数だけが実行されず、例外安全を破ってしまう。 どうすれば「気をつけて書いている」ことになるのか考えてみた。 finallyを都度書く finallyを使えば、例外が起きても終了処理が呼ばれる。とりあえず、これで例外安全にはなる。
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
PHPのSPL系組み込み例外は全部で13個あるんですが、正直、使い分けがよく分かりませんでした。公式ヘルプを見ても、わかったような、わからんような。。 (全部うしろにExceptionって付くので省略してます) Logic系 BadFunctionCall BadMethodCall Domain InvalidArgument Length OutOfRange Runtime系 OutOfBounds Overflow Underflow Range UnexpectedValue 名前の似ているOutOfRangeとOutOfBoundsが全然違うって辺りが罠。 どういうときに使われるのかをPHP本体のソースコードからgrepしてみます。 そもそも、SPLというオブジェクト指向のライブラリを作る上で導入されたのがSPLの例外だったはずだから、本家の使い分けが一番信用に足るはず。。 ソ
意外と知られていないような気がしたので。 普通にタイプヒントを書くと、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などのサブコマンドを生やしている人も多
Prophecyとは phpspec/prophecy PHPUnitと組み合わせて使えるモックライブラリ。 元はphpspecの一部として開発されたもので、phpspecと組み合わせなくても単独で使うことができる。 PHPUnit 4.5からパッケージに同梱されるようになった。PHPUnitの新しいバージョンを使っていれば、composer.jsonに加えなくても使うことができる。 テストダブルとは ユニットテストを書くときに、テスト対象の依存の代替として使うオブジェクトをテストダブルと言う。目的はいくつかある。 依存オブジェクトの準備を手抜きする。100行の準備をしないとテストが書けないとしたらユニットテストが読みにくくなってしまう。 実行しづらいメソッドを差し替える。外部へ通信してしまうもの、I/Oが発生するもの、すごーくたまにしか失敗しないものなどを強制的に変更したいとき。 メソッ
.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
次のページ
このページを最初にブックマークしてみませんか？
『@Hirakuのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
