クラウド的なアレ

日頃Web APIの設計や実装に携わることが多く、とはいえまだまだ未熟だなと自身に感じる部分も多く、何が足りていないのかを知りたいような気持ちがあった。そんなときにこの書籍に出会えた。 日本語で読めるWeb APIに関する書籍だと、Web API The Good Partsが有名。あの書籍も良かったが、出た当時からそれなりに時間が経ってしまったのと、あの書籍の記載内容は少し薄い部分もあり、もう少し何か別のものを、という気持ちがあったが、この書籍はまさにそこを満たすようなものだった。 Web APIの名前付けやリソースの切り方、まではいいとして、それを実際にユーザーに使ってもらうときの権限設定の仕方は実務上非常に重要な関心事になる。 セキュアにするためにどのように区分していくといいのかを示しているのが次の図。 出所：(Kindle Location 4584) また、読み進めていくと、センシティブなデータをどのように扱うかについて記述があった。 参照権限がないユーザーが見にきた場合に、Permissionが足りない、のように返すと、そのエンドポイントリソースが存在していることを認めることになってしまうので避けるべき、というのは一般的な話ではあって、例えばGitHubなんかは見る権限がない状態でアクセスすると404 Not Foundを返す。 このカードを読み取るためのパーミッションがエンドユーザーに割り当てられていないことを意味する。状況によっては、この最後のエラーは情報漏洩と見なされる可能性がある。 (Kindle Locations 5006-5008) ただ、そのリソースは存在するのに404というのは適切なんだろうか？という気持ちはあった。 が、この書籍の中でその回答は得られた。 要するに、その権限のないユーザーの「コンテキスト」においてはNot Foundだということ。ユーザー（コンシューマー）視点で捉えると理解ができる。 同じような話で、/accountsというエンドポイントを指した際の結果がコンテキストによって異なる例が次の図。 出所：(Kindle Location 4753) なんとなく自分の場合、リソースに対する考えが強すぎるのか、 /accounts/C1を用意するとか/accounts?id=C1を用意するとかの対応の考えてしまう。 言い換える

Quarkusを自分でガイド見てこれまで使ってきたけれど、もう少し、他の人がどう使っているのかを知りたいという気持ちになった。 Twitterで時々見かけていた、リアルタイムではそれほど視聴者のいない(笑)、Quarkus Insightsを順に追っていってみよう、という試みを始めた。 まだEpisode 0と1しか見ていないが、それだけでもいくつか収穫があった。（Youtube Liveに慣れてなくてぐだぐだしているところも多いんだけど、徐々にこうやって出来上がっていくのだな、というのが見れて好感を持てた） Quarkusのワークショップ セルフペースでの学習になるけれど、こんなのが紹介されていた。 Quarkus Workshop A hand's on lab about Quarkus quarkus.io 内容を見ると多分驚く。下の方までずらっっっっっとページが続いている。 ただ、これで間違いなくベースが整う。 困った時に見るページ 困った時ってどこ見たらいいんだっけ？なんて話が出ていた。 基本的にこのページの記載内容の通り。 Support When You Need It Quarkus: Supersonic Subatomic Java quarkus.io メーリスがあるのは見落としていた。 早速購読してみたら、数日のところで、Red Hatの日本法人の方たちが中心となって有志で日本語翻訳をしたのでコミュニティに寄贈したい、と申し出ていたのを見かけた。 その投稿から2週間もしないうちに、次のページが公開された。これで日本でもユーザーが増える、かもしれない。 Quarkus - Supersonic Subatomic Java Quarkus: Supersonic Subatomic Java ja.quarkus.io あとは、自分もQuarkusがもっと盛り上がったら面白い、と思っているところもあり、自分が回答できそうな質問が流れてきた時に、ちょっとだけ汗をかいて質問に回答してみた。 役に立てただろうか。わからないけれど。 その他、設定に困ったらどこ見る？という話の流れでこのページが紹介されていた。 すべての設定が載っていて、自分が使っている設定なども検索すれば必ず見つかる。ただ、全設定なので、表示までの速度が結構遅め。今後これ、ど

この書籍のベースになっているPhoenix Projectを読んでなかなか面白かったので関心があった。 DevOpsについて人に話す機会が出てきていることもあり読んだが、この本をベースにチームビルドするのは結構良さそう。 顧客が感じる時間はリードタイムなので、プロセスの改善では、プロセスタイムではなく、リードタイムに注目する。しかし、リードタイムの中でのプロセスタイムの割合は、作業効率の重要な指標になる。高速なフローとリードタイムの短縮を実現するためには、ほとんどかならずバックログとして滞留している時間の削減が必要になる。(Kindle Locations 955) Webアプリの話に置き換えて考えるとわかりやすい。リクエストを受け取ってキューに入り、実際に処理が始まり、処理結果が変える。ユーザーから見るとこのターンアラウンドタイム（TAT）が短くならなければ意味がない、というのは当たり前だし頷ける。 デプロイのリードタイムを短縮するための制約条件の変化については次の4つの順に変化していくと記載されていて、この制約条件を打ち破った場合、通常は次の制約条件は開発部門か製品オーナーとなる。(Kindle Locations 1162) - 環境の作成 - コードのデプロイ - テストの準備と実行 - 過度に密結合なアーキテクチャ これは経験的にもそうだなと思える。 私たちは、ソフトウェアサービスや製品をグリーンフィールドかブラウンフィールドかで分類することが多い。これらの用語は、もともと都市計画やビルの建築プロジェクトで使われていたものだ。グリーンフィールド開発は、未開発の土地を開発することである。それに対し、ブラウンフィールド開発は、もともと工業目的で使われていた土地を開発することで、それらの土地は有害なゴミや汚染物質によって汚染されている危険性がある。都市開発では、多くの要因から、ブラウンフィールドプロジェクトよりもグリーンフィールドプロジェクトの方が簡単である。取り壊さなければならない既存の構築物はないし、取り除かなければならない有害物質もない。 (Kindle Locations 1741-1745) もし組織のどこかでDevOpsをやりたいという話になるときは、可能であればグリーンフィールドで実施した方が、純粋に実施したいことを実施できる可能性が高まりそうな感

英語に課題を感じてる。ここ半年近く、日常的に英語で仕事をする日が週の半分を占めるようになっているので、その中で嫌でも自分の課題というか、微妙なところが目につく。 - この言い回し、くどいな？伝わるのか？誤った意図で伝わっていないか？ - 言いたいことはあるんだが、うまく言葉にならなくてダラダラと喋ってしまっている - なんて言ったんだか全然聞き取れないし、言い直してもらっても状況が変わらない みたいな悩みがあった。 一応、事前に会話内容がクリアに描けているものについてはさらさらと話せるくらいではあるし、Japanese Englishであれば大抵は聞き取れるし、誰かが困っていてきっとこう言いたいんだろうなというのがわかると助け舟を出す、くらいのことはできる。 でも、より高いエンゲージメントを実現したいと思うとこれではまだ不満。 というわけで、何かちょうどいいサービスはないだろうかと思っていたところに、会社からPROGRITの案内を受けた。 話を聞いたり、巷のブログで調べたりしたところ、内容的には結構良さそうだった。 ブログで拾ったのはこんな内容。 プログリットでのリスニング： - 音声知覚：英語の音声を聞いてどのような単語なのか知覚・認識するステップ - 意味理解：知覚した単語が、文章の内容としてどのような意味なのかを理解するステップ 音声知覚ができて初めて意味理解に入れる。 シャドーイング： - プロソディシャドーイング：音を拾って発音することだけに集中するシャードイング - コンテンツシャドーイング：意味理解をして内容をイメージしながら行うシャドーイング（プロソディシャドーイングよりも格段に難しい） 使用する教材はTED動画。e.g. Grit: The power of passion and perseverance, Try something new for 30 days, The surprising habits of original thinkers, How the blockchain will radically transform the economy 進め方（1日の分量）の例： - 音声を聞いて内容理解（1回） - オーバーラッピング（5回） - シャドーイング（50回） いざカウンセリングを受けてみると、 - 音を聞けるようになる