1. はじめに

GoFのデザインパターンにおける、Visitorパターンについてまとめます。

2. Visitorパターンとは

• Visitorという英単語は、訪問者という意味になります。
• Visitorパターンは、データ構造と処理を分離する方式です。
• データ構造の中をめぐり歩く訪問者クラスを用意し、訪問者クラスに処理を任せます。すると、新しい処理を追加したいときは新しい訪問者を作ればよいことになります。そして、データ構造の方は、訪問者を受け入れてあげればよいのです。
• GoFのデザインパターンでは、振る舞いに関するデザインパターンに分類されます。

3. サンプルクラス図

4. サンプルプログラム

ディレクトリ、ファイルの一覧を表示するプログラムです。

4-1. Elementインターフェース

Visitorクラスのインスタンスを受け入れるデータ構造を表すインターフェースです。

Element.java

public interface Element {
    public abstract void accept(Visitor v);
}

4-2. Entryクラス

FileやDirectoryの基底となるクラスです。Elementインターフェースを実装します。

Entry.java

public abstract class Entry implements Element {

    public abstract String getName();

    public String toString() {
        return getName();
    }
}

4-3. Fileクラス

ファイルを表すクラスです。Visitorの受け入れ役になります。

File.java

public class File extends Entry {

    private String name;

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

    public String getName() {
        return name;
    }

    public void accept(Visitor v) {
        v.visit(this);
    }
}

4-4. Directoryクラス

ディレクトリを表すクラスです。Visitorの受け入れ役になります。

Directory.java

import java.util.ArrayList;
import java.util.Iterator;

public class Directory extends Entry {

    private String name;
    private ArrayList<Entry> dir = new ArrayList<Entry>();

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

    public String getName() {
        return name;
    }

    public Entry add(Entry entry) {
        dir.add(entry);
        return this;
    }

    public Iterator<Entry> iterator() {
        return dir.iterator();
    }

    public void accept(Visitor v) {
        v.visit(this);
    }
}

4-5. Visitorクラス

ファイルやディレクトリを訪れる訪問者を表す抽象クラスです。

Visitor.java

public abstract class Visitor {
    public abstract void visit(File file);
    public abstract void visit(Directory directory);
}

4-6. ListVisitorクラス

ファイルやディレクトリの一覧を表示するクラスです。

ListVisitor.java

import java.util.Iterator;

public class ListVisitor extends Visitor {

    // 現在注目しているディレクトリ名
    private String currentdir = "";

    // ファイルを訪問したときに呼ばれる
    public void visit(File file) {
        System.out.println(currentdir + "/" + file);
    }

    // ディレクトリを訪問したときに呼ばれる
    public void visit(Directory directory) {
        System.out.println(currentdir + "/" + directory);
        String savedir = currentdir;
        currentdir = currentdir + "/" + directory.getName();
        Iterator<Entry> it = directory.iterator();
        while (it.hasNext()) {
            Entry entry = (Entry) it.next();
            entry.accept(this);
        }
        currentdir = savedir;
    }
}

4-7. Mainクラス

メイン処理を行うクラスです。

Main.java

public class Main {
    public static void main(String[] args) {

        Directory workspaceDir = new Directory("workspace");
        Directory compositeDir = new Directory("Visitor");
        Directory testDir1 = new Directory("test1");
        Directory testDir2 = new Directory("test2");
        workspaceDir.add(compositeDir);
        workspaceDir.add(testDir1);
        workspaceDir.add(testDir2);

        File element = new File("Element.java");
        File entity = new File("Entity.java");
        File file = new File("file.java");
        File directory = new File("Directory.java");
        File visitor = new File("Visitor.java");
        File listVisitor = new File("ListVisitor.java");
        File main = new File("main.java");
        compositeDir.add(element);
        compositeDir.add(entity);
        compositeDir.add(file);
        compositeDir.add(directory);
        compositeDir.add(visitor);
        compositeDir.add(listVisitor);
        compositeDir.add(main);

        workspaceDir.accept(new ListVisitor());
    }
}

4-8. 実行結果

/workspace
/workspace/Visitor
/workspace/Visitor/Element.java
/workspace/Visitor/Entity.java
/workspace/Visitor/file.java
/workspace/Visitor/Directory.java
/workspace/Visitor/Visitor.java
/workspace/Visitor/ListVisitor.java
/workspace/Visitor/main.java
/workspace/test1
/workspace/test2

5. メリット

Visitorパターンは処理を複雑にしているだけで、「繰り返しの処理が必要ならデータ構造の中にループ処理を書けばいいのではないか？」と感じます。
Visitorパターンの目的は、データ構造と処理を分離することです。データ構造は、要素を集合としてまとめたり、要素間を繋いだりしてくれるものです。その構造を保持しておくことと、その構造を基礎とした処理を書くことは別のものです。
訪問者役(ListVisitor)は、受け入れ役(File、Directory)とは独立して開発することができます。つまり、Visitorパターンは、受け入れ役(File、Directory)クラスの部品としての独立性を高めていることになります。もし、処理の内容をFileクラスやDirectoryクラスのメソッドとして実装してしまうと、新しい処理を追加して機能拡張するたびにFileクラスやDirectoryクラスを修正しなければならなくなります。

6. 参考

• Java言語で学ぶデザインパターン入門

概要

Kubernetesは、コンテナを基としたインフラのオーケストレーションツールです。

非常に多機能で、宣言的な記法でのインフラコード管理によって、柔軟かつ堅牢なインフラストラクチャを構築することができます。その一方で、(Kubernetesのみの知識に関わらず)非常に学習コストが高いという側面も持ち合わせています。

このエントリーでは、Kubernetesを知る上でその前提知識として必要そうなキーワードと、なぜ必要なのかという簡単な説明を書いていきます。

項目については、自分自身がハマったり困ったことがベースになっているため、もしかしたら足りない/多すぎるという意見もあるかもしれません。

※筆者は偉そうに書きますが、筆者の理解が深いわけではないので悪しからず。

ツイッターにて募集をかけてみたところ予想を上回る反響をいただいたので、今回まとめるに至りました。

↓元ネタツイート

【緩募】K8sを始めるために理解が必要なドメイン知識
REST、アジャイル、Git、docker(コンテナ)、IaC、クラウドインフラの基本的な構成、分散処理、マイクロサービス、認証認可

他にもある気がするが、あと何があるだろう？

— inductor@技術書典「う47」 (@_inductor_) 2019年3月6日

必要そうな知識一覧

開発手法/ツール

Docker(コンテナ)

KubernetesはかつてはDockerに強い依存関係を持っていましたが、今はそうでもありません。しかしながら、コンテナというエコシステムを理解するうえでDockerの基本的な構想を知っておくことは必須ですし、Dockerを理解したうえでなぜKubernetesを使うのかというところへの理解に繋げていくのがよいかと思います。

Git

Gitである必要性は必ずしもないかもしれませんが、コードのバージョン管理は必須です。業界標準であるということを踏まえGitとしています。これがないとKubernetesの構成管理は成り立たないですし、アプリケーションのデプロイ自動化などもできないので必須です。

アジャイル

Kubernetsに限らず、コンテナベースのアプリケーションとアジャイルな開発は切っても切り離せないくらい密接な関係を持っていると自分は考えているので加えました。仮にアジャイル開発をしていないとしても、コンテナとアジャイルはなぜ相性がいいのか知っておくべきだとは思います。

マイクロサービス

マイクロサービスはアプリケーション自体の設計もさることながら、インフラ側の構成も非常に重要です。疎結合で分散されたアプリケーションを管理する上では、コンテナやそれを管理するKubernetesは非常に相性が良いものであると言えます。（ちょっとうまく説明できないので誰か代わりにお願いします）

DevOps

Kubernetes(というかコンテナ)を利用したいというモチベーションの1つに、DevOpsを実現するためのプラットフォームとして選定することがあります。
クラウドネイティブとDevOpsにも密接な関係性があると筆者は考えており(要出典)、知らない人は勉強しておきましょう。

Infrastructure as Code(IaC)

Kubernetesの構成管理は原則yamlファイルで行います。IaCの理解は必須でしょう。

CI/CD

テスト書きましょうテスト(吐血)
Kubernetesに限った話ではありませんが、抽象化されたインフラを最大限に生かすための戦略として、テストやデプロイの自動化、それに伴ったパイプラインの構築はもはや必須レベルだと思います。

プロトコル

REST(HTTP)

Kubernetesでは、CLIでの操作を含め、多くの処理がAPI Serverによってハンドリングされています。そのため、HTTP通信の超基本と、それを応用したREST APIの知識は必須とも言えるでしょう。
必須ではないですが、ついででも良いのでHTTP/2についてふわっと知っておくとプラスかもしれません。ついでにgRPCも（なにもわからないけど）

サーバの基本

クラウドインフラの基本的な構成

Kubernetesのプロジェクトを現在管理しているのはCloud Native Computing Foundationという団体ですが、彼らの掲げるCloud Nativeという概念を実現する最も大きなコンポーネントの1つがKubernetesです。
逆に言えば、Cloud Nativeとは何か、クラウドによって実現できるインフラにはどんな特徴があるかといった理解を持っておくことは非常に重要だと思います。

ストレージ

インフラの基盤であるKubernetesにおいて、データ格納先であるストレージも非常に重要な概念です。ただ、オンプレとパブリッククラウドでは必要になる知識がちょっと違うかもしれません。

*NIX OSの基本

コンテナはカーネルの機能であるcgroupsやnamespaceを利用したisolationを行っています。カーネルはLinuxのものを使いますので、みなさんLinuxチョットデキルエンジニアになりましょう（自戒）
というかこれが大体わかったらもうそれだけで勝利な予感がします。

分散処理

分散処理なにもわからない。
Kubernetesはコンテナオーケストレータという立ち位置が非常に強いですが、分散処理の基盤という側面も持ち合わせています。GPUを使った機械学習基盤の構築や、大規模なワークフローをKubernetesのPodを使って動かすなど、単なるアプリケーション基盤に限らず、様々なユースケースもありますので、その特徴は理解しておくとよいでしょう。

セキュリティ

※ただし、これは事前に知っておくべきと言うよりは、こういうものが待ち受けているんだなあくらいに思っておくのがよさそうです。

認証認可

マイクロサービスにおけるセキュリティといえば認証認可ですね（？）
Kubernetesにおいても認証認可の概念は非常に重要で、必要な権限を適切に振り分けるのは永遠の課題ではありますが、Kubernetesの運用者のみならず開発者も基本的な理解はしておくべきだと思います（自戒）

機密情報の管理方法

機密情報の管理は、コンテナ化における最も重要な課題の1つです。
いろいろなツールもありますが、当然サービスや環境の要件によって大きく左右されますので、どんなものがあるのかを知っておくとよりよいと思います。

ネットワーク

インフラ基盤というくらいですから、当然ネットワークの知識も必要です。TCP/IPモデルをベースに、特にL3/L4/L7の基本的な理解はしておきたいですね(筆者無事死亡)

DNS(名前解決)

Kubernetesはサービスディスカバリを目的として内部DNSを抱えています。少なくとも浸透したと言わない程度には知っておくべきでしょう。

雑なまとめ

いやー、多いですね。
SREだとかDevOpsだとか言った組織を実現していくには、多かれ少なかれこれらのスキルセットをベースに持つエンジニアたちが求められます。
もちろん、全てを理解してからなんて話はないと思いますが、こういう世界があるんだなあという大雑把な景色が見えているだけでも、Kubernetes完全理解への一歩に繋がるのかもしれません。

Kubernetesやっていきたいインフラの皆さん、コード書いていきましょう！
Kuberneresやっていきたいバックエンドの皆さん、Linux完全に理解しましょう！

書いてて自分の知識のなさに辛くなってきたのでそろそろおわりにします！！！！！

1．はじめに

こんにちは、SE2年目のtomoです。
SE力を高めるために購入した本を整理していたところ、当時の悩みや興味を思い出して面白い。
ということで、購入した本を紹介しながら、私の2年間をざっくりまとめようかと思います。

今回は下記画像の右2列から抜粋です。
（右が2年前で左が現在、また、読んだ本が上段で、読み切れてない本が下段）

2．入社前　〜ドキドキ・ワクワク（？）期〜

2016年、就活を終えて内定を得たのはSIerでした。
学部は文系（経済）、プログラミング未経験という状態。
ありがちな悩みだと思いますが、そのような状態でSEになることに不安を覚えていました。

2-1.技術面の悩み

上述の通り、SEの知識はゼロ。
まずは資格を、ということで、会社の補助もあり、TACで基本情報技術者試験の講座を受講。
半年後に取得しました。
資格は賛否両論あるかと思いますが、知識ゼロの人が業界の共通言語を覚えるという意味で、意味があったと思います。

また、基本情報ではキャッチアップできないトレンドワードを学ぶため、以下の本を読みました。

-デジタルビジネストレンド

2-2.ビジネス面の悩み

社会人になるの、怖いですよね。（私だけですかね）
卒論もまともに作っていなかったので、文章を構造化することに不安があった私は以下の本を読みました。

-入門 考える技術・書く技術
以下の考え方は今に活きているかと思います。（あれ、できていない？）
　・結論ファースト／箇条書きによる伝わりやすい表現
　・文章を書き出す前にピラミッド状に構造化して考える

3.入社後　〜意識爆上げ期〜

2017年4月、社会人になりました。
最初は新入社員研修です。

3-1.ビジネス面の悩み

研修において複数の課題を感じ、以下の本を読みました。

-考える技術・書く技術
先ほどの入門本の元ネタです。
制限時間ありのレポート作成においてレポートをまとめきれなかったのを課題に感じ、購入しました。
改めて文章の構造を考えてから詳細を書くことを意識した結果、制限時間以内にひとまず完成系を提出できたため、効果はあったかと思います。
B4一枚紙で重要と感じた箇所をメモしていましたが、詳細は覚えておらず、、。
今読むとまた違う発見があると思うので、また読み返します。

-コンサルタントの「質問力」
ユーザーのニーズを聞き出す方法に疑問を持ち、読みました。
以下のテクニックは活きるかと思います。
　・6:4の比率で話すことよりも聞くことを意識
　・徹底的に仮説を立てて当てていく
　・選択肢を与える質問をする

-社内プレゼンの資料作成術
シンプルイズベストを示した1冊です。
SlideShareでもこちらを参考にしたと思われるスライドが散見されます。
複数の情報を1スライドに詰め込んで何を表現したいのか分からなくなっていたところ、この1冊を読むことで改善されました。（社内プレゼンでも分かりやすいとコメントをいただいたので、オススメです）

-孫社長のむちゃぶりをすべて解決してきた すごいPDCA
社内プレゼンの資料作成術を読んで「ソフトバンク、強い」と感じて購入した1冊です。
フローは、「複数の策を同時に実行」→「日次でPDCAを回す」→「最善策に集中する」、というものです。
先日参加したSIX2019でも、「成果が出るかどうかを検証するのがPoCであって、そのコストを許容してくれる上司が必要」との発言があったように、リスクをコストとして捉えることが大切だと感じます。
（できるかどうかは企業文化によるところが大きいと思いますが。。）

4.当時すべきだったと感じる事

実際に何か自分で作ってみるという経験ができると良かったと思います。
理由は以下。
　・机上だと理解に限界がある
　・自分で調べて解決する力をつける

じゃんけんなどのプログラムであったり、大学のプログラミングの授業を受講するのでも良かったかと思います。

5.おわりに

続きはまた後日に書こうと思います。