よいAPIの作り方を教えてくれる本． たとえばcollectionを返したいときに，[ ]としてArrayで返すのか，{ collection: [ ] }みたいにObjectに入れるのか，悩んでたけど，この本読むと，どっちがいいか分かる． API作ってると，細かいところでちまちま悩むので，良い習慣が紹介されてて良い． TwitterとかGitHubのAPIとかではこうなってる，とか実例がたくさんあるのもよい．たしかに悩んだらそのへんのよさそうなAPIを真似して決めると楽そう． API作りたい人は読んでおくと役立ちそう． Web API: The Good Parts 作者: 水野貴明出版社/メーカー: オライリージャパン発売日: 2014/11/21メディア: 大型本この商品を含むブログ (1件) を見る

一昨日インストールした PostgreSQL 9.4 RC1 で可能になった新しいクエリの例。unnest 関数に複数列を渡すのと WITH ORDINALITY オプション指定を合わせて使ってみます。ドキュメントの該当箇所は下記です。 ■ PostgreSQL 9.4rc1 Documentation - Queries - Table Functions 例えば下のように、複数の群から成るサンプルサイズが違う「対応がないデータ」を一つの表形式にする場合。VALUES 句でベタ打ちするとサンプルサイズ最大の群に合わせて NULL 埋めする必要があり、本来無関係の群間のデータを VALUES(…, …, …) に束ねて書くのも変です。 ■ 山崎信也, なるほど統計学とおどろきExcel統計処理第5版, p.67, 2006, 医学図書出版 （リンク先は第7版の紹介ページ） そこで Post

techass.md エンジニアの評価観点について こんにちは。 @katzchangです。 VOYAGE GROUPでは人事評価制度の一つとして技術力評価会というのが年に2回ほど開催されて、半年くらいの仕事から何かテーマをピックアップしつつ、別チームのエンジニア2名とお話をしつつ、なんと評価までされてしまうという、とても楽しい会があります。 評価する側のエンジニアも多様で、ある程度の評価軸はありつつも、それぞれの質問や評価はそれなりに個性が出るものだろうなーと眺めています。ということで、私なりの質問や評価のポイントをいくつか挙げてみます。 質問に対して明確に答えるための手段を知っているか？ 例えば「キャッシュの有効時間はどれくらいか？」みたいな質問をすることがあるとします。当然、「わかりません！」で終わると残念なのは皆知ってるので、頑張って答えようとします。しかし、その場で「xx分です！

REST API用のドキュメントを生成するときにどうやってるかについて雑記を残しとく。 概要 実装とドキュメントの乖離を避けるためには、同じ意味情報を二箇所以上に定義することを避ける必要がある。そのための方法として、実装それ自身か、もしくは実装が参照している何らかのメタデータを元にしてドキュメントを生成したり、テストの実行結果からドキュメントを生成するというパターンがある。 テストから Cookpadでは、autodocというライブラリを利用して、RSpecでテストを実行している途中で得られたメタデータからドキュメントを生成している。これはテストの実行結果からドキュメントを生成するパターン。 これは実現方法としてはかなり特殊な部類。このパターンが最も効果的に働くのは、ドキュメント生成のために余分な開発コストはあまり掛けたくないが、テストは真面目に書いている OR 真面目に書いてほしい、とい

名前 pg_dbms_stats -- 統計情報の管理を行い、間接的に実行計画を制御します。 概要 PostgreSQL は ANALYZE コマンドによりテーブルやインデックスからサンプリングした値を集計して統計情報として保持しています。 クエリ・オプティマイザは、この統計情報を利用してクエリのコストを計算し、最もコストの低い実行計画を選択します。このため、データの量や特性が変化したり、統計情報の精度が不十分であったりした場合には、選択される実行計画が変化する場合があります。 pg_dbms_stats パッケージはこのような予期せぬ実行計画の変化を防ぐための機能拡張です。プランナの処理に割り込んで、プランナが参照する統計情報を事前に作成したダミー統計情報に差し替えることで、選択される統計情報を固定します。「実行計画が運用中に急に変化し、システムの性能が低下する」というリスクを抑えたい場

2014年はOSS（オープンソースソフトウエア）にとって、良い意味でも悪い意味でも忘れられない年となった。アンチOSS派の筆頭であった米マイクロソフトがついに、「.NET」をOSS化。OSSの優位性は揺るぎないものになった。しかしその一方で、「Struts」や「OpenSSL」といったOSSに深刻な脆弱性が見つかり、社会問題にまで発展した。 OSSを使うことが“必須”となった今こそ、ユーザー企業は「OSSのリスク」を直視する必要がある。最も警戒すべきなのは、「OSSただ乗り」が生んだ怪物。寿命が尽きたのに動き続ける「ゾンビOSS」の存在だ。