GoogleがI/O 2019で発表した100のコトまとめ
Googleの開発者向けイベント「Google I/O 2019」が2019年5月7日から5月9日にかけて開催されました。Googleはイベントの中で多数の新発表を行い、イベント終了後に自社のブログで発表内容を「I/O 2019で発表された100のコト」としてまとめていました。 Count ‘em up: 100 things we announced at I/O ‘19 https://www.blog.google/technology/developers/100-things-we-announced-io-19/ ◆ハードウェア 1：低価格なのにGoogleの重要な機能を搭載した「Pixel 3aとPixel 3a XL」 GoogleがPixel 3・Pixel 3 XLの廉価モデル「Pixel 3a」「Pixel 3a XL」を発表 - GIGAZINE 2：Pixel 3
HTTP API の設計方向
見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。
「大規模なUI改修」を行うとどうなるか
アプリケーションを実装していくと、「大規模なUI改修」に遭遇することがある。 あちこちで見聞きした結果、以下のようなパターンがあるように感じたのでまとめてみた。 （UI改修なので基本的にフロントエンドからみた内容） これは一般的に「技術的負債」と呼ばれることが多いが、デザインの負債（UIを置く場所が無くなったり無くなったり、同じ概念のUIが分散したり）である場合も多い。 （ちなみに、デザインの負債は「ダイアログを多用する」とか、「最小画面サイズが大きくなる」とかの形で現れやすい） そして、デザイン負債に対応するために実装の困難なUIが増えるため、技術的負債も高くなる傾向がある。 （サーバサイドの技術的負債がDBの負債に起因する場合が多いことと似ているかもしれない）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロダクションの Rails サーバーの利用メモリがひたすら増加していくような挙動を観測したとき、どう対応するのがよいですか？