はじめに すでに多くの人が見聞きしたことのある「 80：20の法則 」について今あらためて筆を取ろうと思ったのは、実は私自身もこの法則について漠然としか理解していないことに気づいたからです。 ある日のコーヒータイムにたまたま、この法則が話題に上がりましたが、その場にいた友人の多くがこの法則を知らないことが分かりました。とはいっても、私自身もその場で明快にこの法則を説明できたわけではありませんでした。そこで改めて、この有名な法則について復習をして、みなさんに共有しようと考えたわけです。 どうぞしばしの間お付き合いください。 80：20の法則 とは？ MBAの卒業生あるいは履修生なら、80：20の法則は少なくとも耳にしたことがあるはずです。発見したイタリアの経済学者ヴィルフレッド・パレートにちなんで、パレートの法則（Parto Law）とも呼ばれているこの法則は、以下のように表現されています。 「得られた結果の80％は、費やした努力の20％によるものである」 逆に言えば、 努力のうち80％は、結果のうち20％の部分にしか貢献していません。そんなのあり！？ この法則は統計的手法によって示されました。発見されてから200年間の間、これを否定しようとする多くの試みがありましたが、パレート法則の評価は不変のままです。

本は人類の知識の結晶です。実際、読書は私達に多くのものをもたらしてくれます。単に楽しみや見識を与えてくれるというだけでなく、実用的な面から見ても、読書習慣のある人とない人では平均年収が5-10倍異なるというデータもあるそうです。とはいえ、本の正しい読み方を知らないという人が少なくないでしょう。そこで、今回のブログで 効果的な読書の方法 を紹介します。 シャーロック・ホームズはたくさんの名言を残していますが、一番私にとって印象的だったのは、「You see, you do not observe」というものです。訳すならば、「君は見ているだけで、観察できてはいないんだよ」といったところです。 観察は見ることと違って、目の前のものごとを見るではなく、その様子に深く注意を払い、考えたり分析したりするということです。もちろん、観察のほうが見るだけよりも、ずっと多くのことを私達にもたらしてくれます。 読書についても全く同じことが言えます。情報を摂取するにあたり、受動的な姿勢では、読書の効果を出すことができないでしょう。ですから、読書から効果を引き出すために、能動的かつ積極的に本を読むことが大切です。 能動的な読書には、目的意識や、適切な読み方が必要です。ベトナムには”Phương pháp đọc

1. はじめに APIの動作確認をするとき、HTTPヘッダーやリクエストの中身、レスポンスなどをどのようにチェックしていますか？何を隠そう私はずっと、Laravelのロガー一本槍でやってきました…。今日ボスに紹介してもらった、こんなときのための強力なツールをご紹介します。Charles Proxyです。では、 Auto Draft Charles Proxyで端末の通信 についてご説明します。 Charlesは、デバイス間のすべてのHTTP(S)通信をモニタリングできるウェブプロキシツールです。 クライアントがPCブラウザであれ、モバイル端末であれ、リクエスト、レスポンスからHTTPヘッダー（クッキーやキャッシュを含む）までまるっと追跡できます。 では実際に、スマートフォンとコンピューターの間の接続にCharles Proxyを刺してみましょう。 検証環境：

みなさん、今日もLaravelしていますか？今回の記事では Laravel-erにぜひ試してほしい省力化ツール5選 を紹介します。ご興味のあるLaravel-erの方は、ぜひご覧ください。開発するのに役に立つと思います。 MySQL Workbench 「そんなの知ってるよ！」という声が聞こえてきそうです。待って、まだタブを閉じないで！ みんな大好きMySQL Workbenchには、あまり使われていない便利機能がたくさんあります。 まず、このツールのすごいところは、テーブル間・カラム間の関係をEER図（拡張実体関連モデル）でエクスポートできるということです。 EER図があれば、データベースの構造は一目瞭然です。このエクスポート機能は、チームメンバーや顧客に、アイデアや設計を明確に伝えるのに役立ちます。 例として、簡単なデータベースを設計してみます。 usersテーブルとproductsテーブルを、1:Nのリレーションで結びつけます。 方法１:ちまちま作る テーブルを2つ作って…

最近 S3とCloudFrontでReactJSアプリの運用コストを削減 できる方法が効果的ではないかかという悩みがインタネット上で頻度が高く寄せられています。 ここ数ヶ月、サーバー担当者として弊社最大規模のプロジェクトにジョインしていました。規模が大きいですから、お客様がAWSに支払わなくてはならないコストの大きさも半端ではありません。ジョインから3ヶ月ぐらいの時に、運用の安定性を保ったままコストを削減できる方法はないかと、リクエストを頂きました。 色々考えた末、１つの点に思い当たりました。すべてのソースコードはElasticBeanstalk経由でEC2にデプロイされています。AWSの費用が決して安くないことは皆さんもご存知でしょう。 解決方法 EC2の費用が安くないとすると、他の何かに変えてみたらどうでしょうか？　もしできるとしたらどのリポジトリでしょうか？ 本プロジェクトには巨大なソースコード群が存在し、そのソースが各リポジトリに分割され、ヘッドレスモデル的に構築されています。つまり、クライアントのリポジトリ（ReactJSでコード）があり、バックエンドのリポジトリ（PHPでコードされたAPI）もあります。そして改めて検討すると、EC2にデプロイする必要がないリポジトリが見つかりました。それは、ReactJSでコードされたクライアントリポジトリです。 なぜ必要ないのでしょうか？ それは、一度ソースコードをデプロイしてしまえば、私達が取得するのは静的なhtmlファイル、cssファイル、js、画像ファイルだけだからです。そして、そのようなファイルを最も安価かつ簡単に保存できるのは？　間違いなくS3でしょう。 しかし、S3はEC2のように自動スケーリングできないため、アクセス数が多い場合に、どのように処理させたらよいでしょうか。その答えはCloudFrontです。 最終的には、S3とCloudFrontを組み合わせて、顧客のコスト削減問題を実現することにしました。 前提 用意するもの