サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
パリ五輪
moromii.hatenadiary.jp
この記事はFOLIOアドベントカレンダー4日目、Node.jsでthriftを使うことになったという稀有な人のための記事です。 thriftとは Apache Thriftは、RPCフレームワークです。 .thrift ファイルにAPI定義を書くと、binary protocolで通信できるserver/clientのコードを生成できます。FOLIOでは、micro serviceが提供するAPIは基本的にはThrift になっているので、Node.jsで書かれたBFF(Backends For Frontends)がserviceを叩くときはthrift APIを呼び出すことになります。(REST APIが少しだけゾンビのように生き残っています) thrift(を始めとしたRPCフレームワーク)には、次のようなメリットがあります。 binary protocolなのでJSON REST
flowtypeを使ってみて個人的にはまったところ。 v0.65.0時点での話です。仕様なのかバグなのかわからない話も含みます。 enumの罠 flowのenum(正しくはUnion Type)は条件分岐などで、含まれないはずの値と比較しているとエラーを出してくれる。 /* @flow */ type A = "hoge" | "huga" const a: A = "hoge" if(a === "humu") { console.log("hoge") } // 7: if(a === "humu") { // ^ string literal `humu`. This type is incompatible with // 5: const a: A = "hoge" // ^ string enum ただし、これはObjectのプロパティに対して働かない。 /* @flow */
READMEを始め、ソフトウェアのドキュメント全般を書く技術というものをもっと洗練させていきたい。要件定義書のようなものだけでなく、開発方針や設計方針、API定義などなど。 これらのドキュメントをしっかりと整備するだけで、レビューの質も上がり新しい人が入ったときもスムーズに意識のズレなく開発ができる。はずだが、なかなかドキュメントの上手い書き方や管理の仕方というものは、コーディングのそれとは違い議論が活発ではない。 最近試してみたこと そういったドキュメントの中でも、"開発方針"や"設計思想"をどう残していくかということを考えている。それらを残しておくことで、コーディングのときも立ち戻る場所ができ、大きく道を踏み外さなくなる。 例えば、レイヤードアーキテクチャのようなものの"境界"をドキュメントにしていく。MVCでもクリーンアーキテクチャでも何でも良いけど、それらのアーキテクチャではそれぞ
ドキュメントは腐りやすい ドキュメントはどうやっても更新されなくなってしまう。Wikiに書こうか、Confluenceのほうがいいのか、色々置き場所を考えてはみるものの、大きく改善することはあまりない。 その理由のひとつが、コードとドキュメントのライフサイクルが違うこと。元来ドキュメントは「コーディングの前に書くもの」であったし、その意識はなくてもPull Requestに「あのドキュメントも更新しておきます」と書いている時点で、それはライフサイクルが合っていないものを、信頼性の低いプロトコルで同期を取ろうとしているようなもの。 それを解決する手段のひとつが、コードとドキュメントを同じリポジトリに置くということだけれど、READMEが大量にできるというのもそれはそれで見通しもメンテナンス性もあまり良くない。 必要とされるドキュメントの形はさまざま それなら、とコードからドキュメントを自動生
このページを最初にブックマークしてみませんか?
『moromii.hatenadiary.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く