2019-12-31

2019年のまとめと、2020年の目標

今年何やったっけ

昨年末に左足の手術をしたせいで、1〜8月はリハビリばかりの日々だった。しんどかった。

仕事について

少し厳しめなスケジュールの仕事が増えた気がする。
雑な要件のまま実装を進めないといけないことが多く、この状況はなんとかしないといけない。
他にも色々と改善しないといけないことがあるので、どうしたものか。

後輩の教育でペアプロを試してみたが、結構上手く行っている気がする。
「TDDBC札幌2019」でペアプロをやったおかげなので、あのイベントに参加して本当によかったと思う。

来年からは少しずつだが、JavaScript(Vue.jsあたり)やAzureなどを使った業務ができそうな状況になって来ている。
このチャンスを上手く活用して、自分の技術の幅を広げたいところ。

今年参加したイベント

今年は、昨年よりイベントに参加する機会が多かった。
数年前は、少人数のイベントはアウェーな気がして避けていたけど、今となっては積極的に参加するようになった。
単純に楽しいし、勉強になることがたくさんあるから参加することが多くなったのだと思う。

2019-02-09 【2/9@札幌】Oracle Code One 2018 報告会
2019-03-09 【3/9@札幌】Kotlinハンズオン（Java Doでしょう#14）
2019-05-11 PyCon mini SAPPORO 2019
2019-06-01 オープンソースカンファレンス2019 Hokkaido
2019-06-15 TDDBC札幌2019
2019-08-03 〈8/3@札幌〉モブプログラミング&Java開発入門
2019-09-06 v-sapporo MeetUp #2
2019-09-28 CLR/H #110
2019-10-19 10/19@札幌〉Kotlin入門：Kotlinらしい書き方をモブプログラミングで学ぼう！
2019-12-18 ゆるWeb勉強会@札幌スペシャル / 探索的テストを学ぼう！ with TEF道
2019-12-21 〈12/21@札幌〉Oracle Code One報告会 & Javaチャンピオンツアー

2019年の目標

ソフトウェア設計の勉強

「ドメイン駆動設計」がトレンドになっているような気がして、カンファレンスのスライドとかを観たりはした。
ただ、それだけしかしてなくて、実践があまりできていない。

ソフトウェアテスト、テスト自動化の勉強

「TDDBC札幌2019」に参加したことや「テスト駆動開発」を読んだことで、色々と学びがあった。
業務で実践するにはまだまだ知識が足りないので、まだまだ勉強を継続する必要がある。

積み本消化

つまみ食いばかりで、一冊を通して読むことができていなかった。積み本はむしろ増えた。
ひととおり読み終えたのは「テスト駆動開発」くらい。

来年の目標

なんか作ってみる

今年はDiscord4J+HerokuでモンハンBotを雑に作ってみたら、結構楽しかったし、結構便利だった。
来年はもっと色々作ってみたい。
実際に手を動かすことで、ソフトウェア設計・ソフトウェアテスト周りのことも学べるといいな。

積み本消化

つまみ食いする読み方が悪いわけではないけど、必要なときとか、気が向いたときに読むだけでは足りないと感じた。
取り組み方を変えないとダメだなぁと思った。
例えば、毎朝時間を作って読書するとか。
短時間でも、読書をする習慣をつけてみよう。

どこがで発表してみる

最近はイベントに参加することが多くなって、自分も何かできないかなーと漠然と思っている。
例えば、LTだったら比較的ハードルは低いかもしれない。
そういう機会があれば、積極的に参加してみようかなと思う。
そのために、普段からネタになるようなことに取り組まないとなー。楽しみながら頑張ろう。

2019-06-30

TDDBC札幌2019に参加してきました

2019年6月15日に開催された「TDDBC札幌2019」に参加してきました！

f:id:ryu19j:20190630001026j:plain — TDDBC札幌2019会場入り口

agilesapporo.doorkeeper.jp

午前中は和田卓人さんの基調講演＆ライブコーディング、午後はペアプロでTDDとレビューを行いました。

当日学んだことをあとで思い出せるように、感想とメモ書きを書いておこうと思います。

基調講演＆ライブコーディング

speakerdeck.com

上記のスライドを用いて基調講演が始まりました。
FizzBuzzを題材にライブコーディングが行われたのですが、これが本当にすごかったです。
スライドのタイトル通り「見てわかるテスト駆動開発」でした。
何を考えながらコードを書いているのかがとてもわかりやすく、本当に素晴らしかったです。

ペアプロでTDD＆レビュー

■お題 gist.github.com

面識のない人とのペアプロは今までやったことがなかったので、うまくできるか不安でしたが、ペアの方がフォローしてくださったので、とても楽しく行うことができました！実際にペアで考えながら手を動かしてRed→Green→Refactoringを行うことで、楽しくTDDを学ぶことができたと思います！

今回は前半と後半でレビューの時間があったのですが、知らないうちに前半のレビューの対象となっていて、気づいたらマイクを持たされていました。
（てっきり「レビュー受けてみたい人いますかー？」とか言われて挙手するスタイルかなーと勝手に思っていたのですが…）

レビューではたくさんの~~マサカリ~~ ご指摘をいただきました。ほとんどの指摘が「仰る通り」としか言えない正しい指摘でした。
当たり前のことであっても、指摘されて初めて気づけることも多いので、レビューはやっぱり大事だなと改めて実感しました。

いきなりマイクを持たされて少し緊張しましたが、割と落ち着いてコードの説明をすることができたと思います。
コードに対して指摘されたときや、意図の説明を求められたときも意外と冷静に回答できていたような気がします。（回答の８割くらいは「仰る通りです」だったような気もしますが…！）

とても貴重な経験をさせてもらえてラッキーでした！

[質問・指摘内容（うろ覚え）]

* 閉区間の下端点と上端点を持つことのテストを書いた理由
* equalsがJava言語仕様に沿っていない
  * 仰る通りです
* 例外のテストに`@Test(expected = ~Exception.class)`を使用しなかったのか
  * 存在は知っていたが、自信がなかったので使用しなかった
* チェック処理のメソッド名が`check~`
  * 改善例として`require~`として、必須項目が入力されていない場合は例外をスロー
* ゲッターとフィールド名にズレがある
  * 仰る通りです
* テストケース不足
  * 仰る通りです

ペアプロ前半の時点でのコードなので、まだ中途半端な状態なのは仕方ないかなとは思うものの、初歩的な指摘が多くなった印象でした。
TDDのRed→Greenを素早く行いすぎて、Refactoringが十分ではなかったのかもしれないと思いました。
どんどん次に進みたいという気持ちが強かったのも原因かもしれません。

equalsがJava言語仕様に沿っていない部分については、少し考えがあってあえてそういった実装で進めていました。
理由は、ペアの方は第一言語はJava以外の言語を選択されていて、普段Javaを書いている感じではなさそうに感じたので、最初のうちはJava言語仕様に関わる部分に触れたくないなと思ったからでした。
というのも、ペアプロの最初から「これ、Javaの言語仕様だからこう書くべきです」みたいな指摘をしてしまうと、積極的に意見を言えずに萎縮してしまう人もいるかもしれない、と思ったからです。
自分はペアと出来るだけ対等な関係で進めたかったので、まずはequalsをあえて簡単な実装にして進め、ペアプロに慣れてきたタイミングでRefactoringする流れで行こうと思いました。

ただ、今になってみると少し考えすぎだったかもなと思うし、「動作する綺麗なコード」を書きたいのだから、最初からそうあるべきだとわかっていることは指摘するべきだったかなと思います。言葉を柔らかくして指摘するだけで十分だったかもしれません。

■書いたコード github.com

全体的な感想＆まとめ

このイベントに参加する前に予習しておこうと思い、「テスト駆動開発」で少し勉強してからイベントに臨みました。
（第１章〜第１６章までは軽く目を通しました）そのおかげで、基調講演＆ライブコーディングの内容をスムーズに理解できて、新しく知る部分について集中して聴くことができました。

特にライブコーディングでの学びが多かったなと思いました。
リアルタイムでコードを書きながら、それについて的確な説明があることで、こんなに説得力と納得感が生まれることにとても驚きました。

ペアプロはペアの方がうまくフォローしてくださったので、楽しくコードを書くことができました！
参加者全員の前でレビューを受けて、たくさんの~~マサカリ~~ご指摘をもらう貴重な体験ができて本当によかったです。

今回は懇親会にも参加しました。
今までこういったイベントの懇親会には参加していなかったのですが、今回は試しに一度参加してみようかなという気分になったので参加してみました。
（面識のない人しかいない場に乗り込むのは苦手なので…）

参加者に知り合いがいなくてすごく不安でしたが、色々な人たちと話をすることができてすごく楽しく有意義な時間でした！
技術者同士で技術について話したり聞いたりするのはやっぱり楽しい！話しかけてくださった皆さま、ありがとうございました！
今後はイベントの懇親会にも参加していこうと思います。

以上、感想でした。

（おまけ）当日のメモ書き

■メモ書き

テストを書くことで品質管理する、は副作用
分割統治、各個撃破
動作する綺麗なコード
→動作する、綺麗にする

コードを書いていると集中モードに入って、何をすべきかを忘れてしまう
→TODOリストを改訂して進んでいく
→最初は弱い奴から倒していく

Red→Green→Refactoring
リファクタリングが大事！
リファクタリングの沼（いくらでもできてしまう）
→時間制限を設ける
→数で決める（２つの重複した処理を１つにする）

FizzBuzzライブコーディング
・TODOリストを作る
→問題を分割して各個撃破する
→テスト容易性の設計
→大事なのはロジック（３のとき、５のとき、１５のとき）
　 →大事な部分をテストしやすいようにする
　 →プリントする、は難しい。変換する、なら簡単（単純なインプットとアウトプット）
→日本語表記の揺れを整える

■設計する
==== TODOリスト
-[ ] 数を文字列に変換する
-[ ] ３の倍数の時は数の代わりに「Fizz」に変換する
-[ ] ５の倍数の時は数の代わりに「Buzz」に変換する
-[ ] ３と５の両方の時は代わりに「FizzBuzz」に変換する

-[ ] １からxxxまで

-----------

-[ ] 1から100までの数（後回し、怠惰）
-[ ] プリントする
　 →標準出力に出るかどうかをテストするのは難しいし、頑張った割に価値がない（ビューのテストみたい）

■テストを書く
とりあえずfail()
→JUnitがちゃんと動くことがわかる
　 →Junitがインストールされていない、IDEが認識していない、という状況を防ぐ

日本語テストメソッドおすすめ（void 数を文字列に変換する()）
→国際的なチームでなければ
→テストコードはドキュメントだから、わかりやすくあるべき
　 →test01, test02とかだとなんのテストかわからない

テストメソッドの内容（フェーズ）
→準備、実行、検証
　 →あえて下から書いていく
　   →検証を先に書くことで、ゴール（単一の）を明確にするため
　   →たくさんassertがあると何を確認したいかわからなくなる問題

assertの引数の順番
→言語によってexpected, actualの順番が違うので注意

==== TODOリストを改定
- [ ] 数を文字列に変換する
    - [ ] １を渡すと文字列"1"に変換する
- [ ] ３の倍数の時は数の代わりに「Fizz」に変換する
- [ ] ５の倍数の時は数の代わりに「Buzz」に変換する
- [ ] ３と５の両方の時は代わりに「FizzBuzz」に変換する

- [ ] １からxxxまで

どんな風にするか考える
→どんなクラス名、メソッド名
→作る前に使う（クラスを作る前に、テストコードに書く）
　 →使いやすいかどうかを考えるフェーズ

// 準備
FizzBuzz fizzBuzz = new FizzBuzz();

// 実行
String actual = fizzBuzz.stringify(1);

// 検証
assertEquals("1", actual);

↑テストは失敗するけど、エラー内容が変わる
↑最初は簡単な物を選ぶ（最初は大変だから）

public String stringify(int i) {
  return "1";
}

// 準備
FizzBuzz fizzBuzz = new FizzBuzz();

// 実行
String actual = fizzBuzz.stringify(1);

// 検証
assertEquals("1", actual);

↑グリーンになる！（茶番のようで茶番じゃない）
　 ↑テストコードがバグっているのでは？という心配
　 ↑プロダクトコードを使ってテストコードが正しいかを確かめる
　 ↑（欠陥挿入、ミューテーションテスティング）
　 ↑現実のプロダクトコードでは現実的ではない
　 ↑だからテストコードを書くタイミングで行う（だから return "1";）

【リファクタリング】
必ずテストグリーンを確認する
プロダクトコードもテストコードもリファクタリングする
→優先するのはプロダクトコード

==== TODOリストを改定
- [ ] 数を文字列に変換する
    - [x] １を渡すと文字列"1"に変換する => 仮実装
    - [ ] ２を渡すと文字列"2"に変換する => 

新しいテストを書く時は、assertを追加するより、メソッドを増やしたほうが良い
（e2eテストとかのハイコストなテストでは仕方ない）
↑assert文が縦にたくさん並んでいる（アンチパターン）
　 ↑アサーションルーレット
　 ↑たくさんありすぎて、何を確認したいのかわからないし、テストエラーより後ろのテストが実行されない
　 ↑ワンアサーションパーテスト

void _1を渡すと文字列1に変換する() {
  // 準備
  FizzBuzz fizzBuzz = new FizzBuzz();

  // 実行 & 検証
  assertEquals("1", fizzBuzz.stringify(1));
}

void _2を渡すと文字列2に変換する() {
  // 準備
  FizzBuzz fizzBuzz = new FizzBuzz();

  // 実行 & 検証
  assertEquals("2", fizzBuzz.stringify(2));
}

public String stringify(int i) {
  return String.valueOf(i);
}

==== TODOリストを改定
- [x] 数を文字列に変換する
    - [x] １を渡すと文字列"1"に変換する => 仮実装
    - [x] ２を渡すと文字列"2"に変換する => 三角測量

・リファクタリング
引数名の変更

public String stringify(int num) {
  return String.valueOf(num);
}

テストコードリファクタリング
重複の除去
↑２アウト派と３アウト派

void _1を渡すと文字列1に変換する() {
  // 準備
  FizzBuzz fizzBuzz = new FizzBuzz();

  // 実行 & 検証
  assertEquals("1", fizzBuzz.stringify(1));
}

void _2を渡すと文字列2に変換する() {
  // 準備
  FizzBuzz fizzBuzz = new FizzBuzz();

  // 実行 & 検証
  assertEquals("2", fizzBuzz.stringify(2));
}

==== TODOリストを改定
- [ ] ３の倍数の時は数の代わりに「Fizz」に変換する

@Test
void _1を渡すと文字列1に変換する() {
  // 準備
  FizzBuzz fizzBuzz = new FizzBuzz();

  // 実行 & 検証
  assertEquals("1", fizzBuzz.stringify(1));
}

@Test
void _2を渡すと文字列2に変換する() {
  // 準備
  FizzBuzz fizzBuzz = new FizzBuzz();

  // 実行 & 検証
  assertEquals("2", fizzBuzz.stringify(2));
}

@Test
void _3を渡すと文字列Fizzに変換する() {
  // 準備
  FizzBuzz fizzBuzz = new FizzBuzz();

  // 実行 & 検証
  assertEquals("Fizz", fizzBuzz.stringify(3));
}

public String stringify(int num) {
  if (num == 3) return "fizz";
  return String.valueOf(num);
}

前準備の除去（前準備の重複）

@BeforeEach
void 前準備() {
  // 各種テストメソッド実行前に呼ばれる
  // テスト実行順番はランダム（多分ハッシュで散らしている）
  // ↑テストの熟考順による依存を防ぐ
  // テスト実行時間を減らすため、分散並列で動かす。その時にテスト間に依存があるとできなくなる
}

@Test
void _1を渡すと文字列1に変換する() {
  // 準備
  FizzBuzz fizzBuzz = new FizzBuzz();

  // 実行 & 検証
  assertEquals("1", fizzBuzz.stringify(1));
}

@Test
void _2を渡すと文字列2に変換する() {
  // 準備
  FizzBuzz fizzBuzz = new FizzBuzz();

  // 実行 & 検証
  assertEquals("2", fizzBuzz.stringify(2));
}

@Test
void _3を渡すと文字列Fizzに変換する() {
  // 準備
  FizzBuzz fizzBuzz = new FizzBuzz();

  // 実行 & 検証
  assertEquals("Fizz", fizzBuzz.stringify(3));
}

FizzBuzz fizzBuzz;

@BeforeEach
void 前準備() {
  // 各種テストメソッド実行前に呼ばれる
  // テスト実行順番はランダム（多分ハッシュで散らしている）
  // ↑テストの熟考順による依存を防ぐ
  // テスト実行時間を減らすため、分散並列で動かす。その時にテスト間に依存があるとできなくなる

  fizzBuzz = new FizzBuzz();
}

@Test
void _1を渡すと文字列1に変換する() {
  assertEquals("1", fizzBuzz.stringify(1));
}

@Test
void _2を渡すと文字列2に変換する() {
  assertEquals("2", fizzBuzz.stringify(2));
}

@Test
void _3を渡すと文字列Fizzに変換する() {
  assertEquals("Fizz", fizzBuzz.stringify(3));
}

==== TODOリストを改定
- [ ] ３の倍数の時は数の代わりに「Fizz」に変換する
  - [x] ３を渡すと文字列"Fizz"に変換する -> 仮実装, 本実装

public String stringify(int num) {
  if (num % 3 == 0) return "Fizz";
  return String.valueOf(num);
}

==== TODOリストを改定
- [ ] ５の倍数の時は数の代わりに「Buzz」に変換する -> 明白な実装（自信があるときは仮実装しないですぐ作る）

* 問題を小さく分割する
* 歩幅を調整する
  * テスト→仮実装→三角測量→実装
  * テスト→仮実装→実装
  * テスト→明白な自走

テストコードとプロダクトコードが残っていて３年経過
↑振る舞いはわかるけど、「で？」
↑肝心の仕様がわからない

どこまでやるべきだったのか
* テストメソッド名を詳細に書く
  * ３の倍数の時にFizzを返す__3の時にFizzを返す

TODOのインデントはツリーに見えてくる
インデントされた箇条書き

@DisplayName("FizzBuzz数列を扱うFizzBuzzクラス")
class FizzBuzzTest {

    FizzBuzz fizzBuzz;

    @BeforeEach
    void 前準備() {
        fizzBuzz = new FizzBuzz();
    }

    @Nested
    class stringifyメソッドはintを文字列に変換する {

        @Nested
        class その他の数の時はそのままの文字列表示する {
            @Test
            void _1を渡すと文字列1に変換する() {
                // 準備
                FizzBuzz fizzBuzz = new FizzBuzz();

                // 実行 & 検証
                assertEquals("1", fizzBuzz.stringify(1));
            }

            @Test
            void _2を渡すと文字列2に変換する() {
                // 準備
                FizzBuzz fizzBuzz = new FizzBuzz();

                // 実行 & 検証
                assertEquals("2", fizzBuzz.stringify(2));
            }
        }

        @Nested
        class _３の倍数の時はFizzを表示する {
            @Test
            void _3を渡すと文字列Fizzに変換する() {
                assertEquals("Fizz", fizzBuzz.stringify(3));
            }
        }

        @Nested
        class _５の倍数の時はBuzzを表示する {
            @Test
            void _5を渡すと文字列Buzzに変換する() {
                assertEquals("Buzz", fizzBuzz.stringify(5));
            }
        }

    }
}

↑この機能だけでもJUnit5に乗り換える価値がある！

テストケースの件数に不安
↑なんでその他だけ２パターンあるの？
↑実装した人しかわからない
テストのメンテナンスコスト
↑余計なテストコードは削るべき
↑三角測量のテストコードを削るべきだった？
　 ↑メンテナンスコスト最小という観点では正しい？
↑３の倍数、５の倍数の時のテストが倍数のテストになっていない！

======= TODOリスト
- [ ] ３と５の両方の時は代わりに「FizzBuzz」に変換する

テスト対象の数値が微妙
↑境界値でテスト（99, 100, 101）
↑101の時はどういう振る舞い？
↑0の場合は？

テストの構造化とリファクタリング！！！！
↑現在において大事なスキル

2019-01-01

2018年のまとめと、2019年の目標

2018年の目標と結果

楽しくコードを書く

IntelliJ IDEAのライセンスを購入したので、「ゼロから作るDeep Learning」を読み進めながら、IntelliJ IDEAを使って写経した。
他には「Vue.jsとFirebaseで作るミニWebサービス」でも同じように写経した。
普段の仕事では使わないことだったので、楽しく新鮮な気持ちでコードを書けていたと思う。
ただ、コード量的には全然書いていないので、2019年は少しずつコードを書く量を増やしていきたい。

積み本消化

読み終えた書籍は少なかったけど、2017年と比べるとちゃんと読むようになった。
途中で読む時間が取れなくて間が空いてしまったり、その時読みたかったところだけ読んでそのままになってしまったりと、途中まで読んだ書籍が多くなってしまったので、それらの書籍をしっかり読み終えたいところ。

今年読んだ書籍

読了

IntelliJ IDEAハンズオン
Effective Java 第２版
SQL アンチパターン
ドラゴンクエストXを支える技術
Vue.jsとFirebaseで作るミニWebサービス

途中まで

Javaパフォーマンス
ゼロから作るDeep Learning
Pythonではじめる機械学習
Effective Java 第３版
レガシーコード改善ガイド
増補改訂版Java言語で学ぶデザインパターン入門
Clean Architecture
なるほどデザイン

仕事について

良くも悪くもそつなくこなしている感じだった。
与えられた仕事はちゃんとできているけど、それだけしかしていないのでは？と思うことがある。
（仕事でのコミュニケーションを円滑にするために、色々目立たない工夫はできていると思うけど）
仕事でやってみたいことや改善したいことについて、もっと積極的にやって行きたいなと思っている。
また、今年から仕事でGitを使うようになり、DockerやAzureなども使っているのけど、雰囲気で使ってしまっているので、それらもちゃんと勉強したいなと思う。

他には、私の部署に新人が配属された。以前に私の下に後輩が配属されたのは１回だけで、その後輩はプログラマ志望って感じではなかったし、私が前職を退職することが決まったあとに引き継ぎ相手として私のところにきたので、私が本当に後輩に教えたいことを教えることはできなかった。
今回の新人はプログラマ志望で、上記のような事情もないので、少しでも自分が教えられる何かを伝えたいなと思っている。
今まで私がたくさんの方々に教えてもらったり、助けてもらったように。

あとは、WordPressとデザイン周りをほんの少しだけかじった。今まであまり関わらなかった分野なので少し新鮮だった。
WordPressが全然わからなくて、Gutenbergとか新しいものも出てきて混乱していたので、WordPressコミュニティの勉強会に参加した。
普段参加する勉強会とは参加者の雰囲気が違って面白かった。
最低限の知識は欲しいなって思ったので、優先度は低いけど勉強したいところ。

仕事以外で覚えていること

DBスペシャリストを受験した。午後１が54点。思っていたより惜しかったので、ちゃんと勉強しておけばよかった。
OSC行った。機械学習周りの題材が多く感じた。CentOS本もらったけど読んでない。テスト周りの話を聞いたけど、そのあと勉強してない。勉強しよう。
札幌のJJUGに参加した。コミュニティに参加すると刺激になるので、たまに参加したい。
体がボロボロで、病院に通うことが多かった。健康に気を使ったり、鍛えたりしなければ。
プライベートで色々失敗して、ここ数年で一番落ち込んだので、2019年はこの失敗を糧に頑張りたい。

2019年の目標

ソフトウェア設計の勉強

コードを書いていて、どう書くのが良いか考えている時間が多いなと感じていた。
同じチームのすごいコーディングが速い先輩は「ある程度はパターンが決まっているから速くコードが書ける」ようなことを言っていたので、それが少しでも実感できるレベルになるまで頑張る。そして、2018年よりコードを書くようにする！

ソフトウェアテスト、テスト自動化の勉強

自分が携わっているプロジェクトでは、テストコードは一部だけ書いているが、あまり効果がないように感じている。
テスト自動化が大事なのはわかっているつもりだけど、具体的にどこにどんなテストコードを書くのが効果的なのかがわかっていないのだと思う。
その辺りが理解できるように、また自動化すべき箇所、手動テストしなければならない箇所を切り分けられるようになりたい。

積み本消化

積み本は日々増えていく。消化せねば。
まずは機械学習の書籍を読むのを再開したいな。
DockerとかGitとかも雰囲気で使っているので、ちゃんと書籍を読んで勉強したい。

2018-05-03

Ansible勉強用の環境を構築する

Ansibleを使う機会がありそうだったので、ちょっと勉強してみる。
まずは、自分のPCでAnsibleを試すための環境を構築してみた。

www.ansible.com

環境

MacBook Air (2013 Mid)
VirtualBox 5.2.10
Vagrant 2.0.4

VagrantでCentOSを２つを起動して、CentOS（以下「Server1」と呼ぶ）からCentOS（以下「Server2」と呼ぶ）に対して、Ansibleを実行できるようにする。

VirtualBoxをインストール

公式のインストーラを使った。

Oracle VM VirtualBox

Vagrantをインストール

これも公式のインストーラを使った。

Vagrant by HashiCorp

VagrantでCentOSを起動する

まずは、適当な作業ディレクトリを作成しておいて、コンソールから以下のコマンドを実行して、Vagrantfileを作成する。

vagrant init

Vagrantfileが作成されるので、そのファイルの内容を編集して、CentOSが２つ起動できるようにする。

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "bento/centos-7.2"

  config.vm.define "server1" do |server|
    server.vm.network "private_network", ip: "192.168.33.10"
  end

  config.vm.define "server2" do |server|
    server.vm.network "private_network", ip: "192.168.33.11"
  end

end

編集したら、以下のコマンドを実行して起動してみる。

vagrant up

ちゃんと起動しているかvagrant statusを実行して確認してみる。

$ vagrant status
Current machine states:

server1                   running (virtualbox)
server2                   running (virtualbox)

Server1にAnsible実行環境を構築

Pythonのインストール

Ansibleを実行するための色々をインストールする。
今回はPython3.6をインストールしてみる。

Python 3 Support — Ansible Documentation

IUS Community Projectのリポジトリを追加。

sudo yum install -y https://centos7.iuscommunity.org/ius-release.rpm

Pythonとその他パッケージをインストール。

sudo yum install -y python36u python36u-devel python36u-libs

python3.6って入力するのが面倒なので、シンボリックリンクを作成。

sudo ln -s /usr/bin/python3.6 /usr/bin/python3

試しにPythonのバージョンを確認してみる。

[vagrant@localhost ~]$ python3 --version
Python 3.6.5

Ansibleのインストール

今回はAnsibleをpipからインストールするため、まずはpipをインストール。

sudo yum install -y python36u-pip

こっちもシンボリックリンクを作成しておく。

sudo ln -s /usr/bin/pip3.6 /usr/bin/pip3

Ansibleをインストールする。

sudo pip3 install ansible

これでインストールは完了。

Ansibleを動かしてみる

hostsの作成

まずはhostsファイルを作成して、Ansible実行先のサーバ（今回はserver2に対して実行する）に関する内容を入力する。

vagrant-machine ansible_host=192.168.33.11 ansible_port=22 ansible_user=vagrant ansible_ssh_private_key_file=/home/vagrant/private_key

hostsに記述したansible_ssh_private_key_fileで指定した場所に、server2のprivate_keyファイルを格納する。
private_keyはVagrantfileを作成したフォルダの下に格納されている。
.vagrant/machines/server2/virtualbox/private_key このファイルをscpコマンドやツールで、server1に送る。

ansibleコマンドを実行

hostsが格納されているディレクトリでansible all -i hosts -m pingを実行して、うまくいけば以下のように表示される。

vagrant-machine | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

これで、Ansibleをとりあえず動かす環境が作ることができた。

2018-01-01

2017年のまとめと、2018年の目標

2017年の目標と結果

仕事覚える

転職して１年以上経った。
前職では保守作業がメインでコードを書くなんてほとんどしなかったけど、
今はちゃんと業務でコードを書いて、設計もしている。
Java8のLambdaやStream等もちゃんと使っている。
前職のままだったら、まだ使えていなかっただろう。
最近は見積もりが課題なので、ちゃんと意識しながら経験値を積もうと思う。

コードを書く習慣をつけよう

GitHubで草生やす活動をしようと試みたけど、続かなかった。
いつの間にか草を生やすことが目的になってしまって、
プライベートな予定等でコード書けなかった時のモチベーションの落ちがひどかった。

積み本をなんとかしたい

全然消化できなかった。
新しい本を買ってはつまみ食いするような形で、
少し読んで満足するような読み方をしていることに気づいた。色々なことに興味があったこともあるが、その結果中途半端になってしまったと思う。
もっと計画的に、継続して取り組む必要があると思う。

2018年の目標

楽しくコードを書く

無理して毎日GitHubに草生やし続ける必要はないが、
可能な限り継続的に続けられるようにする。
そのために、その時自分が興味があることに取り組みたいと思う。
昨年、Raspberry PI、Arduino、Google Homeを購入したので、
今年はまずそれらを使って色々遊びたい。

積み本消化

まずは仕事ですぐ使えるものの方がモチベーションが上がりそうなので、
Java、設計、データベースに関する書籍を優先して読んでいこうと思う。
毎日30分〜1時間くらい本を読み、月に１冊読むペースで進めようと思う。

2017-01-01

2017年の目標

昨年１２月に転職して、この機会に何か新しいことを始めたいと思い、ブログでも書いてみようかと思いました。

とりあえず今年の目標でも書いてみましょう。

仕事覚える

覚える。そしてちゃんと考えて行動する。

コードを書く習慣をつけよう

Java8まわりをちゃんと理解できていないので、勉強しよう。

あとはSpringまわりは触れておきたいと思う。

GitHubも使っていきたい。

JavaScriptとかもやっていきたい。

積み本をなんとかしたい

気になった技術書はとりあえず買ってしまうのだけど、読めていないので消化したい。

まず積み本整理しよう。

年末までにどこまで出来ているかなぁ。