エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

マイクロサービスってバズワードに釣られてはいけない

きっかけ

下記の記事を見て、自分なりにまとめとメモ。
なんというか、自分も釣られる側な気がして、考えが足りてなかったなと反省の念も込めてる。

マイクロサービスはもう十分 | プロダクト・サービス | POSTD

マイクロサービス

下記サイトから引用

個別に開発された小さなサービスを組み合わせて、一つのサービスを提供するというものです。

マイクロサービスとは何か? デジタル変革の時代を生き残るための、テクノロジー入門 - Customer Success

マイクロサービスへの準備

マイクロサービスが全知全能の銀の弾丸ではない。
正と負、どちらの効果も持っており、状況次第では負の側面が多く出ることもある。

サイト内で言っていた前提条件

  1. ラピッドプロビジョニング
  2. ベーシックモニタリング
  3. ラピッドデプロイメント

上記条件をすべて満たしていたとしても、本当に負の側面がないか考慮する必要がある。
処理を分散することの問題は、マイクロサービスにも存在しうるので、目をそむけてはいけない。

ラピッドプロビジョニング

スケールアップ・ダウンに耐えられる人材がいるかどうか。
それも一人だけでなく、複数人が各チームに散らばっていること。

ベーシックモニタリング

パフォーマンス計測手法が確立しているか?
確立してない場合、マイクロサービスで分断することによって、どこの何が原因なのか分からなくなるだけ。

ラピッドデプロイメント

迅速なデプロイ方法が確率されているか?
すべて手動の場合、マイクロサービスで分断されたサービスをすべて手作業でした場合、事故る確率は高い。

記事を読んでの感想

存在している問題点から目を背けていたかもしれない。
まだ、本格的にマイクロサービスを適用している現場に言ったことがないから、夢見てたかもしれないな。
結構、バズワードって魅力的に見えるから、飛びつきたくはなるけど、用心しなければいけない。
新手の詐欺かもしれない心持ちで、検討する必要があるなと思う。

Java9 Reactive Streams 試し実装

きっかけ

Java9のリリースが迫っているのと、ITproの記事見て試したくなったから。
あとは、Typescriptで非同期の処理を書くことが非常に多いので、Javaでもやりたくなった。

Reactive Streams

非同期処理を実現するための仕様。
非同期処理を採用しているライブラリとして、RxJava/Akka Streamsが有名。

データの流れに着目したプログラミングスタイルで、Publish-Subscribeモデルの実装ができる。
※Publish/Subscribeは、Observerパターンの発展系みたいなもんだという認識でいる。

非同期にしなければいけないってものでもないが、データを作る側と使う側が疎結合になるので、非同期処理に移行しやすくなる。

java.util.stream.Streamインタフェースとは別ものってことには、要注意。

Publish-Subscribeモデルの処理の流れ

http://itpro.nikkeibp.co.jp/atcl/column/15/120700278/061900041/sequence01.png

このフローは、RxJavaも同じ。
※Akka Streamsは知らない。。。

そして、定義されているインタフェースは、下記の通り。

  • Flow.Publisher
  • Flow.Subscriber
  • Flow.Subscription
  • Flow.Processor

実装

とりあえずITproの奴を真似して作った。

import java.util.concurrent.Flow.Subscriber;
import java.util.concurrent.Flow.Subscription;

public class SampleSubscriber<T> implements Subscriber<T> {

    private Subscription subscription;
    private final String name;

    public SampleSubscriber(String name) {
        this.name = name;
    }

    @Override
    public void onComplete() {
        System.out.println(name + ": " + Thread.currentThread().getName() + ": Complete.");
    }

    @Override
    public void onError(Throwable arg0) {
    }

    @Override
    public void onNext(T item) {
        // 配布されたデータを出力する
        System.out.println(name + ": " + Thread.currentThread().getName() + ": " + item);

        // データの要求
        subscription.request(1);
    }

    @Override
    public void onSubscribe(Subscription subscription) {
        this.subscription = subscription;

        subscription.request(1);
    }

}
import java.util.concurrent.Flow.Subscriber;
import java.util.concurrent.SubmissionPublisher;
import java.util.stream.IntStream;

public class Sample {

    public static void main(String[] args) {
        SubmissionPublisher<Integer> publisher = new SubmissionPublisher<>();

        // Subscriberの生成と登録
        Subscriber<Integer> subscriber1 = new SampleSubscriber<>("Sub1");
        publisher.subscribe(subscriber1);

        Subscriber<Integer> subscriber2 = new SampleSubscriber<>("Sub2");
        publisher.subscribe(subscriber2);

        Subscriber<Integer> subscriber3 = new SampleSubscriber<>("Sub3");
        publisher.subscribe(subscriber3);

        // データの登録
        IntStream.range(0, 5).forEach(publisher::submit);

        // 非同期で処理が終わってしまうので、実行終了するまで一時的に待つ。
        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        publisher.close();
    }

}

実行結果

Sub2: ForkJoinPool.commonPool-worker-1: 0
Sub2: ForkJoinPool.commonPool-worker-1: 1
Sub2: ForkJoinPool.commonPool-worker-1: 2
Sub2: ForkJoinPool.commonPool-worker-1: 3
Sub2: ForkJoinPool.commonPool-worker-1: 4
Sub3: ForkJoinPool.commonPool-worker-2: 0
Sub3: ForkJoinPool.commonPool-worker-2: 1
Sub3: ForkJoinPool.commonPool-worker-2: 2
Sub3: ForkJoinPool.commonPool-worker-2: 3
Sub3: ForkJoinPool.commonPool-worker-2: 4
Sub1: ForkJoinPool.commonPool-worker-3: 0
Sub1: ForkJoinPool.commonPool-worker-3: 1
Sub1: ForkJoinPool.commonPool-worker-3: 2
Sub1: ForkJoinPool.commonPool-worker-3: 3
Sub1: ForkJoinPool.commonPool-worker-3: 4
Sub2: ForkJoinPool.commonPool-worker-2: Complete.
Sub1: ForkJoinPool.commonPool-worker-3: Complete.
Sub3: ForkJoinPool.commonPool-worker-1: Complete.

最初、全部表示されへん!なんでや!って思ったら、非同期処理だから終わってるから表示されないやん!って事に気づいた。
Thread.sleep入れてるのは、そのため。
なんか全部見れる上手い手ってあるものかが気になる。

感想

Filterまで紹介されていたけど、今回は基本的な部分のタッチのみ。
非同期は覚えておいて損はないと思う。
そのうち、ビルドシステムもJavaで書くようになるだろうね。
Gradleは、ピュアJavaじゃないけど、非同期での実装がやりやすくなると、効率的なビルドが実現できるのではなかろうかと、ココロの中で思ってる。
※もしかしたら、知らないだけで、もう出来てる?

ForkJoinPoolって、たしかスレッド管理のやつだったよね。
あんまり使われてるイメージはないんだけど、裏の仕組みで必須なのかな?
どっかでキャッチアップしないとダメだな。

参考サイト

最新Java情報局 - Java SE 9の非同期処理ライブラリ、新概念の「Reactive Streams」を学ぶ:ITpro

タスク

ForkJoinについて理解しておく

【書評】Being Geek

Being Geek ―ギークであり続けるためのキャリア戦略

Being Geek ―ギークであり続けるためのキャリア戦略

目次

  • 第1部 キャリアの形成
  • 第2部 マネージメント
  • 第3部 日々の仕事に必要なスキル
  • 第4部 変化

読書日

2016.03.22

感想

いつもの内容まとめ。
個人の意見もメモってるので、書いてないことも書いてある。

第1部 キャリアの形成

キャリアのための行動

システム思考

ギークな人とは、世界を明確に区別できる信条を持っている人。
システム思考を絶対と考える。
通用しないときは、もろい物ができあがる。
特に人間は、システム思考に当てはまらない要素を多く含んでいる。

キャリアの青写真

キャリア > 目の前の仕事
今していること、これからすべきことを考えることは重要。
キャリアは、人事・上司の評価で充実するものではない。
ゴールを決めることで、道中にある決断をしやすくする。

大切なことは3つ

なぜか分からないが、「3」には力がある。
経済は、社会・共産・資本。勉強は、やる気・根気・暗記。
キャリアも同じく3つ。
方向性、成長、成果。

成長

成長するには、戦略が必要。
なんでも勉強するのは、時間がかかりすぎる。
また、成長しない人は、死でいるも同然である。

死んでいないかは、下記の内容をチェックする。

  • 失敗を経験したか?
  • 意義を唱える人がいるか?
  • 学びの内容を説明できるか?

失敗から学び、恐れないことが成長することになる。

成果

他人からの評価を高めるには、有言実行しかない。
ただ、有言実行は難しい。
頼まれたことを、相手が認めるまでやりきる必要がある。
または、できないことには「No」を言う。
安易な「Yes」は、信頼を得られないだけでなく、疲弊する。
いわゆるデスマーチが起こる。

Noを言う場合は、Noといったときの評価の低下と、Yesを言ってできなかったときの評価の低下を、天秤にかける。

複雑なことを簡単に

成長は、今日が昨日の繰り返しになってはいけない。
成長の判断基準は、知識。
以下に工夫して新しいものができるかが重要。
知識を使いこなせるかが、大事。
クイズ番組は、知識を使いこなせてない人の集まりな感じ。
なぜそんなに分かるのに、それを使えないのか考えると、大した人ではないのだと感じる。
教授もそういう人が多い印象。
論文述べるのはいいけど、現場適用はあなた達が考えてくださいって姿勢に、ものすごく苛立ちがある。

転職にあたって考えるべきこと

会社が嫌いという理由では、転職するのに十分な理由ではない。
怒りは、まともな物事を考えられなくなる。
冷静なときに、出した答えが転職かどうか、よく考える。

面接での答え方

質問の種類

  1. 背景を尋ねるもの
  2. 問題解決能力
  3. 自由回答

いづれにせよ、質問の意図を正しく理解することが大切。
とりあえずしゃべるは、悪手。
いい加減なことをいうより、「わかりません」の方がいい。

自分という人間を知らせる

質問の意図が分かって、答えが出ているなら、話すだけ。
その場合、簡潔に述べなければいけない。

面接官のボタン

面接とは、相手の情報を引き出す儀式。
面接官の情報も引き出す。

面接を担当するのは誰か

構造化された面接であれば、面接準備済みで、目的に沿って進む。
流れを読んで、質問の兆候を予測し、何を欲しているのか理解する。
構造化されてない面接の場合、面接官が準備不足。
面接が長くなりやすいが、その分、相手の情報を得られるので、攻略方法も発見しやすい。

第2部 マネージメント

企業文化

知るには、人と話すしかない。
文化は、人が作るもので、人を理解できなければ、文化を知ることはできない。
会社の文化は、行動の結果できていることが多い。
会社の核になっている可能性が高いので、常に注意している必要がある。
キャリアの形成にも影響してくる。
転職=キャリアではない。
転職する理由が、キャリアアップって言っている人は、だいたいおかしい。
形成するキャリアの方向性が合わなかったなら分かる。

第3部 日々の仕事に必要なスキル

ナードハンドブック

ナードとは、日本でいうところのオタクに近い。
何かに熱中して、物事に精通している人間。

マネジメントのシステム

マネージャとは、他人に干渉されながら仕事する人。
扱うものが、ビットから人に変わる。
やるべきことは、戦略的に考えて忘れること。
意図的に忘れても、問題が起きないような仕組みを作ることが仕事。

タスク管理は、大まかに把握しておく。
維持に手間をかけすぎない。

プレゼンテーション

ダメなプレゼン

  • スライドが多い。(MSの寺○さんかな?)
  • 文字が多い(海外エンジニアに多い。漢字があるって、こういうときに役立つ)
  • 1スライドに条法が多い

良いプレゼンをするには

絶え間ない練習と、機転の良さ。
失敗は、よくあること。
複数の目を持った人と話して、可能な限り一般論に近づける。
沈黙を意図的に入れて、内容に区切りを入れる。
沈黙を恐れていると、早口になって何も分からないってことがよくある。

第4部 変化

査定

  • 業績の良し悪しより、仕事内容を焦点にする
  • 議論であり交渉である
  • 予想外なら、一旦冷静に考える

評価よりも中身を重視する。
期待されていることと、それが実際にできているかを見る。

マネージャとコミュニケーション

マネージャになるパターン

  • 意志をもってなる
  • 小さな選択の結果、なってしまった
  • 命令でなった

すべてリスタート

エンジニアとして培ったスキルは、あまり通用しない。
今までと違うスキルが必要になる。
ミーティングの増加、抽象化のフィルタリング、変化球への対応。。。

空白

重要な人の退社

膨大な知識と技術を持っている人の場合、いれば安心だけど、実際はいなくても問題ない。
正答なのか判断しにくくなる。
不測の事態が、発生したときに問題になる。
それを乗り切れれば、後人が育ってくる。

権力・影響力が強い人の場合、文化が変わるだけ。

情報痛が辞めた場合、情報伝達が悪くなる。

全体感想

ギークになりたきゃ、戦略持って物事を学んでいくしかないってのが、読んだ感想。
何も考えずに仕事をこなしているだけでは、ギークにはなれないと感じた。
※この本だけから学んだわけではないが。。。

あと、ギークになろうと思ったら、組織にいると意外と障害があるのではないかとも思った。
それを避けて、楽してやりたいことをやるためにも、組織的な役割と問題の回避方法を知っておいて損はないだろうとも感じた。

eclipse4.7 新機能まとめ

Eclipse 4.7

f:id:suzaku0914:20170708062419j:plain

毎度のことながら、よくお世話になるIDEなので、キャッチアップのために調査。
最近は、TypeScriptやっているせいか、Visual Studio Codeを起動することが多くなってしまったけどね。。。
今回は、地味めなデザインだな。
いつもは、キラキラした派手な画面の印象があるが。

公式サイト

本家

Eclipse Oxygen

Pleiades

日本語化 Eclipse 4.7 Oxygen オキシゲン | MergeDoc Project

変更内容

全部は無理なので、気になった箇所だけ。
もっと知りたい場合は、参考サイトに貼ったリンク先が内容が濃い。

カバレッジ分析

カバレッジ計測のプラグインであるEclEmmaが標準で装備。
EclEmmaにクセがあり意図しない挙動があるようだが、通ってないコードを見分けやすくなった。
以前に調べたことがあったので、そちらを参照してもらえればと。

suzaku-tec.hatenadiary.jp

Git

いろいろ操作性が改善したらしい。
自分は根っからのSourceTree派なので、あんまり興味が沸かなかった。。。
説明は、下記のリンクを参照。

Eclipse 4.7 Oxygen 新機能 30+ / Java 9 を試そう! - Qiita

修正内容が、かなり多い。
Gitを覚えることの重要性が伺える。

トリガーポイント

ある特定のブレークポイントを通過した場合だけ、トリガーポイントに設定した箇所でとまるようになる機能。
機能の共通化している箇所で、特定のブレークポイントに入ったときにだけ、共通部分のロジックをデバックしたいことはあるはず。
それが、楽にできるようになったってことだろうね。
以前は、共通部分に入る前にブレークポイント貼って、止まったあとに、共通部分にブレークポイント貼ったりして、かなり面倒だった。

二重起動抑止

今までなかったのか。。。
eclipseは重いから、そもそも二重起動しようと思わなかった。
システム的に防止してくれるなら、誤操作で起動は減るかもね。

ウィンドウ > 設定 > 実行/デバッグ > 起動 から、「起動中に終了して再起動する」にチェックを入れる。

エディター切り替えの改善

ワイルドカードの利用が可能になった。
マウス操作しがちだから、あんまり使わないが、覚えると楽なのはたしか。
今は潤沢なメモリもあるし、コマンドによるエディタ切り替えを、覚えて損はないと思う。

参考サイト

qiita.com

大変参考になりました。

【Software Design】2017年7月号 及川卓也のプロダクト開発の道しるべ リーンキャンバス まとめメモ・感想

きっかけ

リーンスタートアップに釣られた。
たぶん、自分がいましている開発もリーンスタートアップに分類されるような気がしたから、まとめメモと感想を書くに至る。

リーンスタートアップ

起業家が一番恐れることは、作ったサービスが顧客に届く前にリソース枯渇すること。
最初に考えたアイディアが当たればいいけど、そんなことは稀。

これを成功に導くために行う考えが、リーンスタートアップ
やることは単純で、仮設→検証→修正を繰り返すだけ。
もしくは、構築→計算→学習とも表現される。

口で言うのは簡単だが、実際にやるとなったら大変。
やることは誰かに求められているものをリソース枯渇する前に作ること。

リーンキャンバス

事業計画相当のものを1枚のキャンバスで表現したもの。

構成要素として下記の内容が存在する。

  • 課題
  • 顧客セグメント
  • 価値の提案
  • ソリューション
  • チャネル
  • 収益の流れ
  • コスト構造
  • 主要指標
  • 優位性

課題と顧客セグメント

顧客にとって重要なのは、製品ではなく課題が解決されるのかどうか。
課題が明確化してないのに、それを解決できる製品は売れなくて当然。

そして、その課題をどのような顧客が持つのか具体化することで、付加価値を高めるのは何なのかを明確化できる。

価値提案

どのように位置付けられるかを示す。
既に存在している別製品のメタ表現が期待されている。

ソリューション

課題を解決する機能。
ラフでOK

チャネル

顧客へ届ける手段。

収益の流れとコスト構造

ビジネス起こすんだから必須の考え。
事業をどうやって成立させるのか考える。

主要指標

製品の有効性を測るために見るべき指標を決めておく。
複数見ることもある。
段階や見るべきタイミングも考慮しておく。

優位性

強豪が簡単に真似出来ないものを考える。

感想

起業家の視点が足りてないからだろうか?
あんまり頭に入ってこなかった感じ。
なんかのシステム開発に望む時は、ココらへんをもうちょい意識してやってみよう。
たいてい、隠されていて、何考えているのか分からんところが多いけどね。。。
何年もシステム開発できるとも限らないし、起業家の考えは早めに身につけたいな。

【雑記】Typescriptと充実感が得られてないと感じた原因の考察

きっかけ

仕事でTypescript使っているけど、なんか仕事しても充実感?達成感が得られないので、考察した結果をメモる

現状

やっていることは、データの橋渡し。
ハードからあがってきた情報を、クラウドへ打ち上げる前くらいのところを担当している。

クラウド上に展開されているアプリに食わせるために、データを加工しているのが主な仕事かな?
あとは、ハードからあがってくる情報を抽象化するってのもある。

考察

おそらく、グルーコードばかり書いているからだろうと思われる。
なんというか、結果がダイレクトに見えるところじゃないからかも知れない。
ハードは、操作が関係してくるから、作ったら操作して動けば、嬉しいと思う。
しかし、俺が作っているのは、ハードの凄いコードが打ち上げてくるデータの加工。。。
どうしても、ハード側のコーディングの方がすごそうに見えてしまうってのが、心の中である。

前まではJavaばかりやってきたので、ネイティブ系のプログラミングには、憧れがあるのかも知れない。
Javaエンジニアなら、共感してくれる人が多いと信じたい!
無性にWebと関係ない箇所のプログラミングをやってみたいって感覚に、とらわれる事がある。

やっていることは、重要なことだと思うけど、それを実感しにくいんだよね。。。
バグが起きたら、障害切り分けのために真っ先にこっちに問い合わせがくるのも、結構シンドイ。。。
最初は、分かんないことが多すぎて、いろんな人に聞いて回ったりするのが、心理的にくるものがある。
おかげで、全然関与してない部分のログを見れるようになってしまった。

これからどうするか

書いて思ったが、意外と俺凄いんじゃね?って思えてきた。
実感しにくいのが、問題だね。。。
振り返ると、意外と凄いことしてたんだなと思う。
システムの全体像を把握しているわけなんだから。
ただ、自画自賛はちょっとキモいって感じるけどね。。。

仕事で充実感を得られなかったら、たまに振り返って、やってきたっことを見直すのはありかもしれない。
成果が見えにくいならなおさら。
たまに、振り返りの機会をもうけようと思う。