Single Page Application を作る場合、Web API も作ることになるので、勉強のために購入して読んでみた。 以下、感想と読書メモ。
Web API は JSON over HTTP とも言える。REST API とは呼ばない。
Web API を提供する対象として、未知のたくさんの開発者(LSUDs)と既知の小数の開発者(SSKDs)がある。大半のアプリは SSKDs が対象になるだろうな。今作っている Web API もそう。
Web API のエンドポイントの設計は REST と同じ。 ただ、単語をつなげるときアンダースコアを使っていた。 ホスト名と揃えるならハイフンの方が確かに良いかもしれない。
レスポンスデータは JSON で返すとして、API で配列を返したいときに配列のまま返すか、 オブジェクトでラップするかは悩む。
オブジェクトでラップすれば
というメリットはあるけど…。自分の中ではまだ結論が出ていない。
という風に HTTP の仕様にきちんと従う。 全部 200 を返してレスポンスボディにエラーコードを入れる、なんて行儀悪いことはしてはいけない。
独自の HTTP ヘッダーは定義することがあるかもしれないが、独自のメディアタイプの定義はやりすぎだな。 HTTP クライアントが対応していない可能性高いし。
API バージョンはパスに入れる派だな。 パスに入れておけば使う側は必ずバージョンを指定することになるわけだから。
あと、API のバージョン管理はセマンティックバージョニングで。
オーケストレーション層は BFF (Backend For Frontend) と同じかな。 汎用的な Web API と、それをクライアントが使いやすい形に束ねて加工した Web API を提供する。 Web とモバイルみたいに、クライアントが増えてきたらやることになりそう。
Web API も Web サービスなので、セキュリティは当然気をつけている。 XSS や CSRF はフレームワークがサポートしてくれるが、 パラメーターの改ざんだったり、大量アクセスへの対策は自前で作りこむ必要がありそうだ。
最近は夜に MacBook を開く時間が 30 分くらい確保できる日が増えてきた。まぁその時には疲れ切っていて、マンガやネットを見てしまうことがままあるのだけど。
IT コミュニティへの参加はまだまだ無理そう。平日夜や休日は子育て優先。唯一自由がきくのは平日の昼休みくらいだ。
その昼休みに先日、id:shunsuk 氏とランチをご一緒する機会があった。お互いの近況に始まり、テックな話からビジネス寄りの話までと、貴重な話が聞けて非常に有意義だった。
テックランチとでも言おうか。いろんな人とこういった時間を作れたらとは思うが、その繋がりをほとんど持っていないことが、最近の悩みだ。
起業やスタートアップへの参加は今のところ考えていないけど
といったことに興味があったので読んでみた。
ストックオプションはあらかじめ決めておいた金額で株が買える権利と理解。 あらかじめ決めておいた金額よりも株価の方が高ければ、 権利を行使して株を買ってから売却することで、 その差額が利益になる、と。 株をもらえるわけではなかったんだね。
シリーズAやシリーズBといったシードラウンドで、 スタートアップの価値がどう評価されて株価が上がっていくのか。 また投資を受けることで株の保持率がどう変わるのか。 それらの流れが図表にまとめられていて非常に分かりやすかった。
発行する株式の数については見当たらなかったのでネットで調べた。 例えば資本金1000万の場合、 1株50000円にするなら200株、 1株500円にするなら20000株、 という風に1株の金額を小さくすれば発行する株式の数が増えていく。 株式分割も同じかな。
本書で得た知識を使う機会は今のところ無さそう。 ただ、将来どうなるかはわからない。 プライベートプロジェクトが軌道にのって起業、ってなればいいな。 そのときは再び本書を熟読することになるだろう。 知りたかったことはだいたい知れたので、 知的好奇心は満たされた。
WEB+DB PRESS Vol.94 を読んだので、感想をメモしておく。
仮想マシンやロードバランサを使った VPC 構成のサービスを作ることになりそうなので、 サービスをスケールさせる際に何を監視して判断基準にすればいいか勉強になった。
というか、Microsoft Azure でこういった特集は無いのかな？
Kotlin を最初見たとき Swift っぽいなという印象だった。 本書を読んで、その印象はさほど変わっていない。 まぁ、ところどころ Swift とは違う点があって、Swift の方が良いなと思うことはあった。 fun よりは func だな。あとプロパティの getter と setter を書くところも、好みと違う。
Kotlin は公式の開発言語じゃないので、Android アプリ開発は Java でいいかなと思っていた。 Java8 の機能も一部使えるようになったみたいだし。 ところが Kotlin 1.1 で async/await が導入されると知って、Kotlin に気持ちが傾いてきた。 非同期は Rx より async/await で書きたいからね。
Electron の用途は Web サービスのクライアント開発が多そう。 本特集で作った Twitter クライアントと同じような進め方で、 他のサービスのクライアントも作れそうだ。
Web テクノロジでネイティブアプリを作るためのプロダクトは群雄割拠。 その中でも Electron がウケた理由は、 モバイルに比べてリソースが豊富なデスクトップアプリケーションが対象だったから、 というのはある気がする。
「それ設定で」ていうのは悲しいことに結構遭遇する。 動きが変わるとマズイ(それが改善であっても)ので、 デフォルトは既存のままにしておいて、 設定で有効にするってね。 その結果、ソースコードがどんどんスパゲッティになっていく。 結局は信念という精神論になっちゃうんで、なかなか無くならないんだろうな。
「一人前」の人の下に「見習い」の人をつけるのではなく、 「見習い」の人たちは「見習い」どうしで切磋琢磨させる、 というのがプロスポーツ的で面白かった。 ただ、顧問エンジニア的なビジネスをやっているソニックガーデンだからこそ可能、 という印象は拭えないな。 人月ビジネスにぜひ風穴を空け続けていただきたい。 いいぞもっとやれ。
RDS や Azure SQL Database といった、マネージドサービスで済ませることができればいいんだけど。 ハイスペックの仮想マシンで SQL Server や PostgreSQL を動かすことも今後ありそうなんだよなぁ。 そのときはメルカリみたいに、バックアップ専用のスレーブを立てて、 オンラインバックアップを取る構成を採用することになるだろうな。 使うデータベース製品は違えど、方針は参考にできそう。
Re:dash 良さげ。 最近、自分もデータ分析基盤を構築したけど、 そのときは Elasticsearch と Kibana を使った。 知っていれば Re:dash 試したのにな。 開発者向けの基盤だったので、Elasticsearch のクエリよりは、SQL の方が使いこなしてもらえそう。 Windows 限定だったので、SQL Server + Reporting Service(または Excel) でも良かっただろうな。
Rails 最近使っていないから、Ruby と Rails の情報は本連載頼み。 Puma は Heroku にデプロイするために使ったことがある。 素直に実装した Rails アプリケーションだったので、 Unicorn から Puma へ移行しても特にトラブルは無かったと記憶している。 そうか、Rails 5 からはデフォルトのサーバーになったのか。 まずライブラリ開発者が嵌ることが多そうだ。
地下鉄七隈線の野芥駅近くにある『パティスリー リンク』に行ってみた。 この店は福岡の情報番組で紹介された『土鍋プリン』が話題みたいなんだけど、 プリンよりもケーキでしょ。 ってわけでお店の名前がついた『リンク』と『苺ショートケーキ』を買って帰った。
『苺ショートケーキ』は生クリームが非常にあっさりしていた。 1ホールいけそうなくらいに。 これほどのあっさり生クリームは経験無いかもしれない。 ただ、苺がちょっと酸っぱかったかな。
『リンク』はビターで大人向けの味かもしれない。 生地に間の生クリームはこちらも非常にあっさりしていて、 ビターな生地がいっそう引き立っていた。
デパートに出店していてもおかしくない味とお値段だった。 土鍋プリンがショーケースの場所を取っていて、ケーキの種類が少なかったのが玉に瑕かな。
ES2015 + React の開発環境を Browserify で構築していたけど、 近いうち CSS もバンドルすることになりそうなので、 Webpack に移行することにした。
ブログに手順をメモしておく。 新規にプロジェクトを作成するときも同じ手順でいけるはず。
npm で必要なパッケージをインストール。
# 実際は 1 行 $ npm install --save-dev webpack \ webpack-dev-server \ babel-core \ babel-loader \ babel-preset-es2015 \ babel-preset-react \ file-loader
Webpack の設定ファイル webpack.config.js はこんな感じで書いてみた。
module.exports = { entry: { javascript: __dirname + "/src/index.jsx", html: __dirname + "/src/index.html" }, output: { path: __dirname + "/dist", filename: "bundle.js" }, module: { loaders: [ { test: /\.js[x]?$/, exclude: /node_modules/, loader: "babel", query: { presets: ["react", "es2015", "stage-1"] } }, { test: /\.html$/, loader: "file?name=[name].[ext]" } ] }, devtool: "source-map", resolve: { extensions: ["", ".js", ".jsx"] } };
あわせて package.json の scripts も修正しておく。
{ "scripts": { "start": "webpack-dev-server", "build": "webpack" } }
これで npm run build でビルドが、`npm start' で開発サーバーが起動できるようになった。
webpack-dev-server 便利。
