表題の特集を読みました。ページ数は少ないので、さっくりまとめられていいですね。自分はマイクロサービスについては初心者です。全体としてマイクロサービスはどれくらいの大きさになるのかというのは、初心者の自分が最初に思い付いた疑問です。特集を通読すると、若干の幅があるように感じます。細かく刻んでいるのは、第1章の増田さんだと思います。分割を試みるべきとしています。この段階で、新たに二つの疑問が生じました。一つは、「マイクロサービスに階層はあるのか?」というものです。説明を読んでいると、なんとなく階層はないようなイメージがあります。階層化できるくらい強い依存があるのなら、最初から一つでいいような気もする・・・のでしょうか?もう一つの疑問は、「マイクロサービスはいくつまでならバラして大丈夫なのか?」というものです。大丈夫というのは、メリットがデメリットを上回っているのか、に置き換えていいです。メリットは以下が挙げられていました。変更にかかる時間が短くなること、コストが下がることデメリットには以下が挙げられていました。通信のオーバーヘッドが発生すること障害発生時の原因追跡や復旧が難しくなること全体像を理解するのが難しくなることなんとなくですが、二桁後半あたりから、人間の頭では全体像を理解できなくなってきそうな気がしますね。以下、各章を見ていきます。アプリケーションを「ばらばら」にする理由アプリケーションをいくつかのサービスに分割します。分割というのは、実行環境を分けることです。して分割されたサービスをマイクロサービス(複数形でマイクロサービシズ)としています。マイクロサービスが低コストになった理由に、実行環境の仮想化や、クラウド上で実行できるサービスの拡充が挙げられていました。これについては、自分の理解が不十分な気がしています。「直列・並列」の2軸で説明されていたのは、非常にわかりやすいと感じました。モノリシックなサービスを上手に切り分けるコツとはまず、どう分けるか?どれくらいの大きさで分けるか?という話がありました。ここについては分かりやすく、特に変だなというところはありませんでした。非同期的なサービスでも、アクターモデルとイベントモデルの2つがあると述べられています。個人的には、イベントモデルに若干かすったことがある程度で全然わからんのですが、とにかくパフォーマンスを上げる、もしくはスケールさせるために同期を捨てている、という感覚は持っておきたいと思いました。面白かったのは、サービス間の(通信)プロトコルが何が適しているかというトピックで、HTTP(REST)がトップだったことです。ちなみに次におすすめされていたのは「クラウドサービスの独自プロトコル」でした。マネージドサービスで、非同期的なイベントモデルを扱うのに適しています。逆に言うと、シンプルな同期的な結合であった場合は、慣れ親しんだHTTPで問題ないということですね。一つ気になったのは、購入キャンセルの例で購入キャンセルのイベントに対して各サービスの動作がきちんと整合していなければなりません。システムとして全体の状態を管理してトランザクションするしくみになっている必要があるでしょう。あるのですが、そのトランザクションの仕組みをどう確保するかは相当大事なのでは・・・と思いました。直後に書いているRedisのPub/Sub機能とかはイベントモデルを実現する手段に過ぎないようですし。)が紹介されています。ここらへんからマニアックになっていきます。名前くらいは聞いたことありますが、マイクロサービスの文脈で語られるのだなと思いました。他の背景もあるような気がします。Next.jsをVueのライブラリだと思っていた自分には全然わからない。Meshサービス個別に監視ツールを導入したとき、システム全体の監視はどうするのかという問題があります。サービスメッシュとは、新設したサービスメッシュ層で監視に必要な情報(ログ)を収集する仕組みになります。難しすぎてよく分かりませんでした。数が増えて全体的な監視が難しくなった時の解決策として、最近注目されているようです。おわりに自分みたいな何もわからない人から、ガチ勢まで読ませる内容だと思います。一点気になったのは、字数を収めるために、日本語が若干おかしいような印象を受ける文がいくつかあったかなということです。削りに削って、いま自分が読んでいる文章があるのだなと察せられます。こんな感じのタイムテーブルで行われた、大規模なJavaカンファレンスです。https://ccc2019fall.java-users.jp/timetable.html今回から、講演の一部が「ステップアップセッション」という初心者向けとしてラベル付けされていました。参加したセッションの多くがこのステップアップセッションになりました。qiita.comQiitaでJavaといえばこの人です。「今年はGradle結構やったのでアウトプットしてみました」ということを話していて、今までたくさんアウトプットしている人も新たにチャレンジしていてすごいなと思いました。スライドの具体例がとても丁寧で分かりやすいです。自分はGradleは初心者未満でした。ライブラリを増やすとかくらい。いえ今回のセッションで、「じゃあ明日からbuild.gradleのメンテよろしく!」って言われても泣きながらOKできるレベルにはなりそうな気がします。github.com独自例外クラスの中に、finalのプロパティを持たせて、受け手に情報を渡せるようになります。例外を「投げる」ときはその名の通りthrowを書くのですが、その理由が説明されていたのが良かったです。資料のよくわからないところを聞いてしまったが、資料のアラを突っ込んだ野暮なものでした。雰囲気をつかむところが大事なのかなと。入門ということで詳しく説明されませんでしたが、実際try-with-resourceで書くときのリソースって何なんでしょうね?ファイルとか?DBアクセスとかはもう少し汎用的なところで書くような気がする。これはステップアップセッションになっていませんでしたが、それに入れても良いかなと思いました。自分がJUnitに関して初心者であること、JUnit4から5に移行したいと考えている身であることから、お役立ちのセッションになりました。アノテーションが導入されていたのがJunit4からだというのは初めて知りました。3以前は使ったことがないので。Junit5だと、クラスやメソッドがpublicじゃなくてもいいのかというのはあまり意識していませんでした。関係ないような...?Junit5への移行のメリットとして、assertAllで全部のテストを実行してくれることがありそうです。Junit4だと一か所でも落ちると、以降を実施してくれないので、Assertionを複数おいている場合はフラストレイティングな気がする。-Javaプログラムが動く仕組み-資料は以下です。講演者がめちゃくちゃ緊張していた気がします。JVMについて全く中身を勉強したことがないので、「こんな用語があるのか~」くらいの感想でした。GCについては時間を割いて説明されていました。いくつか種類があるのを初めて知りました。以下の記事などを見て勉強したいと思います。gihyo.jp絵で説明しているのでふわ~とイメージが頭の中に入っていく感じでした。今回出てきた用語を追うことでさらに理解が深められると思いました。後ろに参考資料もついています。backpaper0.github.ioこのころには大体燃え尽きているのでいいセッションがなかったら帰っているのですが、今回はスピーカー・内容ともに楽しみだったので参加しました。DIの仕組み、および内部生成ではなくインジェクションを使うメリットが説明されています。今までなんとなく把握しているものの、うまく説明できないレベルでしたが、今回はっきりしました。Beanとコンポーネントは大体一緒というのは「そうなんだ、よくわからなかったけどそりゃ分からんわけだ」という感じでした。講演者は、主観だとしたうえで、フィールドインジェクションよりコンストラクタインジェクションを使うべきだとしました。IDEAだと、フィールドインジェクションはコンストラクタインジェクションにするように警告されます。コンストラクタインジェクションを使うべきと言っていいと思います。いえ、その理由がよくわかっていなかったので明快になってよかったです。まとめ今回のセッションは、自分の興味を惹かれるものがたくさんあってよかったです。ステップアップセッションのレベル感は自分の予想した通りで、それも良かったかなと。触ってない分野はちょっと難しいなと感じますし、少しやっている分野については有意義という感触でした。来期もこの枠組は設けて欲しいなと思いました。おまけ初心者向けは埋まるのが早いのでキャパをチェックすべきでしょう。私は一つのセッションが満員で入れませんでした。紙でもらったタイムテーブルにはキャパが記載されていますが、HPだとないですね。Fall参加記Tweet広告を非表示にするもっと読むコメントを書く2019-10-19嫉妬と向き合う最近「嫉妬なんかダサい、自分を高める努力をしろ」的な言説をよく見ます。個人的には大筋賛成なのですが、モヤっとすることもあるのでもう少し細かく言語化しようと思いました。先ほどの主張はざっくりすぎるので、以下の3つに分解しました。嫉妬感情は醜い嫉妬で他人の足を引っ張ってもお前の人生は豊かにならないそういうのを止めて自分を高める努力をすべき嫉妬感情は醜い自分の考え:そうでもない。感情そのものを否定する考えは自分にはないです。なくすことも難しいんじゃないかなとも。感情が出てくるのはしょうがないですが、その後の行動をどうするかの方が大事だと思います。嫉妬で他人の足を引っ張ってもお前の人生は豊かにならない自分の考え:決めつけはよくないと思います。相対評価を気にする人の場合、自分より上にいる人を叩き落せば、幸せになると思います。他のパターンでいうと、正義感を持って見知らぬ人をぶっ叩くと幸せになると聞いたことがあります。表に出しませんが、僕も他人の不幸話は嫌いではありません。いえ、周りにそこまでしたい人もいないし、よく知らない人を叩くのは悪いことだと思っているので上記のような行動を起こしていません。自分もそう思う主張なので特に追加したいコメントはありません。まとめそういうわけで、冒頭にある主張をして来る人にモヤッとした場合は、「この人は簡単そうに言っているけど実は嫉妬感情に打ち勝って今があるのかもしれない」と思うことにしました*1。それはそれとして、他人の足を引っ張って喜ぶ人は普通に悪人なのであまりそういった人に関わらないような人生にしたいです。書評Javaのプログラムを書いているとき、「これはベストな書き方なのか?」という疑問は常にあると思います。ネットで調べる、レビューを受けるといった、確認方法はいくつかあると思いますが、その一つが本書になると思います。大型本この商品を含むブログを見る表紙の情報量が非常に多いのが特徴です。「はじめに」に書いてあるのでほぼ合っていると思います。オススメな人Javaをある程度お仕事で書いてきた体系的に学びなおしたいお仕事で書いてきたというのは、実際に稼働するコードを書いた。他人の書いたコードを読んだり直したりしたことがある、という意味です。特徴トピックは多岐にわたりますが、全般的にめちゃくちゃ絞り込んであります。「本格入門」であって入門書ではないので、ある程度文法を分かっている前提で進みます。筆者のこれまでの経験を生かして、「結局どうすればいいか」が書いてあります。インタフェースのデフォルト実装をとりあげます。抽象クラスとどのように使い分けるのかという疑問について、「インタフェースのデフォルト実装は基本的に使わなくてよい」と簡潔に答えています。理由としては、デフォルト実装は、Javaの「過去のバージョンとの互換性*1」のために生まれたという、Javaの歴史を感じるものになっています。納得感のある説明になっていると思います。デザインパターンGoFのデザインパターンは23種類もあって身に着けるのが大変ですが、本書では9つに絞って紹介しています。結城『デザインパターン入門』に比べると、書中ですべてのコードを載せているわけではありませんが、実際に使いそうな例になっています。Factoryパターンでの呼び出し側のコードは以下の通りです。}}ただ、個別のパターンの解説の詳しさは、結城本のほうが上回っています。このパターンでは「工場」を増やすのは簡単です。OracleFactoryは既存の実装に影響を与えずに追加できます。新しい「部品」、HogeSettingsを追加しようとすると、すべての既存の「工場」に影響が出てしまうので大変です。そのような説明が結城本に記載されています。本書でも記載はありますが、個人的には結城本を読んで初めてちゃんと理解できた印象です。「わかっている人にはこれくらいの説明で十分」という感覚ですかね。記載のないもの後半で、デザインパターンや各種ライブラリの説明がありますが、基本的には各クラス内で、どのように書くべきかという説明が中心になっています。設計的な話はあまりないのかな*2という印象です。まとめブログタイトルに「濃縮する」と書いた通り、コンパクトに必要な記載を詰め込んでいるのが本書の良いところだと思います。余談ですが、私は6年くらい前に筆者たちが所属するアクロクエストテクノロジー株式会社に1日インターンに行ったことがあります。当時は1ミリもプログラムを書いたことがなかったはずなのになんで行ったのか全く覚えていませんが、こういった形でまた巡り合うことになるとは、不思議な縁を感じます。14:19『Java本格入門』で、Javaの知見を体系的に濃縮するTweet広告を非表示にするもっと読むコメントを書く2019-07-28楽しいリモートワークリモートワークリモートワーク(テレワーク)*1を1週間連続で実施したので体験まとめ記事です。前提として私は一人暮らしです。背景リモートワークを推奨する期間があり、それにのっかりました。その期間では同僚たちが会社からいなくなるので、自分も出勤してもしょうがないかなという雰囲気でした。事前準備・リモートワーク環境構築やると決めたら色々必要な準備をこなしました。各種設定が必要でしたが、申請とかで待たされることは特になく、スムーズに進みました。最終的にPCを家に持って帰って準備万端です。やったこと基本的には家で一人でコーディングしていました。入社して間もないので、分からないことができたらslackのオープンなチャンネルでメンション飛ばして聞いていました。slackでの電話会議もありましたが、特につつがなくできており*2、その点で特に効率の低下を感じることはありませんでした。これまで「困ったらslackで聞く」ということをしたことがなかったので、今回それが結構有効だと気づけたのが収穫です。洗濯を初めとした家事がはかどりました。入社したばかりで出来ることが少ない自覚があったので、「仕事が全く進まなくなったらどうしよう...」という懸念がありました。周りのサポートもあり何とかなりました。具体的には、次やることを決めるにあたっての的確なサポート、タスクの遂行時に「誰に聞いたらいいか」がハッキリしていたことです。聞きすぎて邪魔になってはいけないと思いますが、適当なタイミングで聞けていたと思います。ちなみにタイミングに関しては、相手の状況がまるでわからないので、対面で尋ねるような機を伺う*3ことをせず、素直にメンションを飛ばしていたような気がします。何より通勤時間がゼロになったので、その分寝る時間が増えたのが良かったです。今後も頃合いを見てリモートワークをしたいと思います。*1:違いはないものと思っています。現職ではテレワークと言われていますがリモートワークの方が広まっている印象なのでそうします。単行本この商品を含むブログを見る邦題のイメージからは、統計学を使って不正を見抜くんや!みたいな印象を持ちますが、実際はデータの間違った使い方を指摘する側面のほうが強いです。Deviations*1』です。邦題の『データは騙る』の方が少し上回っているかと思います。最近、成功者が「成功した人は○○している」と言うたびに「はいはい生存バイアス」と返される流れをよく見る気がします。なんとなく、思考停止の感じが出てきて嫌だなと思ったので、妥当な指摘かどうか確認したく、本書を手に取りました。読後に冒頭の問いを振り返ると、「まあ妥当な指摘なんじゃないですかね」という結論になりました。以下、学びになったことを記載します。私の言葉で自己選択バイアスを説明すると、Aという選択をした人としなかった人とを比較して何かしらの差異を述べようとしたとき、実際は別の要素がその違いに影響を及ぼしているという誤解のことを指します。本書中の例を以下に引用します。「大学を卒業した人間は、退学した者に比べて平均で五四パーセント多く稼いでいる。したがって、卒業証書には経済的な意味がある」ここにも自己選択バイアスが見られる。大学に行くことを選択し、卒業できるように一生懸命に勉強した学生は、途中で大学を辞めた人とはさまざまな面で違ってくるのではないだろうか。私が、なぜ難解としたかというと、実際に自己選択バイアスを見抜き、その裏側にある真因を指摘するのは難しいと思ったためです。自分にとって違和感のない主張に対してはすんなりと受け入れてしまうためにさらに難しくなると思います。自己選択バイアスに敏感になれればいいのですが、それが難しい場合にも他者の指摘を受け入れて自分の固定観念を見直せればいいなと思いました。アンケートQ平均への回帰スポーツのような実力に対して、結果がばらつく場合、ある年度でトップの成績を収めた人は、その前後の年度ではそこまで優れた成績でないことが多いとのこと。この場合、平均への回帰は、「真の実力への収束」といってもいいと思います。読者の想定レベルが低い?本書では、時折常識的な指摘すぎてアホかと思ってしまうことがあります。グラフについての章を取り上げます。ここでは、「縦軸や横軸の目盛りは省略してはならない」と大真面目に書いていました。意外とデータに対する世間のリテラシーが上がっているのか、もしくは自分の周囲だけなのか、どちらにしてもだいぶ簡単な内容だなと思いました。常識の力、厄介さ本文中で、常識的に考えればおかしいような主張が論文として世に出ていた事例が紹介されています。「超能力が存在する」「特定のアルファベットから始まる人は早死にする」など。筆者はそれらの主張のもととなる論文・データがおかしい理由を丁寧に*2説明しています。代表的な理由としては、自分の主張を支持するデータを抜き出したためです。筆者は、自分の持つ常識を大事にしようと述べています。一方で、気をつけるべきこととして、今回読んでいて正しかったのは自分の常識ですが、これが間違っていると突きつけられるときがかならず来るということがあります。そのとき、自らの考えに固執せず、柔軟に変えられるかどうかが大事だと思います。本書は全19章とボリューム盛りだくさんですが、最後の19章はこれまでの振り返りになっています。自己選択バイアスや、誤ったパターン化など、重要だけど難しい概念を思い出せます。まとめ爆発的に増大しているデータや分析に対して、どう判断したらいいかわからなくなっている人にはいいと思います。当レビューで取り上げた以外にも、役立つ概念がたくさんあります。22:15レビュー『データは騙る』Tweet広告を非表示にするもっと読むコメントを書く2019-07-11目標設定、好きなこと、得意なこと、なりたい姿について今日はふわっとしたことについて考えます。やっていると目標設定を課せられることがよくありますが、私はこれが好きではなく、苦手です。考えてみると、いくつか理由を思いつきました。(目標を立てた段階で、それがどれくらい難しいことなのか判断つかない)目標に対して、達成したかどうかの判断基準がイマイチだから計測可能でない目標に関係ない評価に関わってくるからしかし、こうも考えています。これが得意になれば、好きになるのでは?と。評価についてはそんなに気にしなくていいし、定量的な目標は、うまく考えれば立てられるような気がしています。好きなこと自分の好きなことはなんだろう、と考えると、1日10時間寝ること散歩することカフェ読書と、仕事に関係ないものが並びます。今自分が100億円持っていたら上記のような生活を送ります。残念ながらそんなお金はないので仕事をしています。仕事に限定して好きなことを考えると、現段階だとやや曖昧だなと感じています。そこで、以下の手法をとってよりクリアにしていこうと思います。好きなこと(と思われるものも含む)を書き出す。色々なことに取り組み、実際に好きだったか記録する。その際、今まで取り組んでいないことにもチャレンジすることと、すぐに諦めずにしばらく続けることを意識する。振り返って1.の作業をもう一度やる。2.を補足すると、仕事において成長していくためにはチャレンジして継続していく姿勢が不可欠と思いますが、自分の場合それが結構エネルギーを要するもので、意識的にやっていかないとできないと思っています。得意なこと「好きなことより得意なことを仕事にしたほうがいい」という言説を聞きます。得意なことも、好きなこととほぼ同じ手順で発見できると思っています。一つ追加してやっておきたいことがあります。それは他人の得意な事柄を見つけることです。他人の得意不得意について考えることで、自分のそれについても考えやすくなると思われます。仕事に限定すると、「スタンダードなサーバーサイドエンジニア」が今のなんとなくのイメージです。すればなれるのかというと、コードが書ける、アーキテクチャ・フレームワークが理解できる、設計ができる、チームワークができる、アプリケーションを作るにあたって重要な概念を理解している*1、そんなところでしょうか。まとめこれら4つについて、定期的に考えていくと良さそうです。無から構築するわけではなく、最近あった出来事について、自分は何をしたか、何を思ったかを記録してそこから考えると、より正しい答えが見えてくるような気がします。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。