2018-09-04

Clean Architectureを読み終わりました

書評

Clean Architectureを一通り読み終えたので書評です。

Clean Architecture 達人に学ぶソフトウェアの構造と設計Ｒｏｂｅｒｔ　Ｃ．Ｍａｒｔｉｎ：生活・実用書 | KADOKAWA

評価

★★★★★★★☆☆☆（7/10）
評価の目安はこちら

オススメできる人

ソフトウェアアーキテクチャに関する勉強をしたい人
クリーンアーキテクチャパターンの概要をを知りたい人

オススメできない人

クリーンアーキテクチャパターンをコードレベルで知りたい人

感想

クリーンアーキテクチャパターンについて書かれているのかと思い購入したのですが、
パターン自体の説明については少なかったので想像していたのとは違う内容でした。

ただ、ソフトウェアアーキテクチャに関する概論といった意味で捉えると参考になる内容が多かったと感じました。
プログラミングのパラダイム、設計の原則、アーキテクチャの方針と
ソフトウェアアーキテクチャを考える上で必要なことが書かれているのではないかと思います。

クリーンアーキテクチャパターンのドメイン/ユースケース/コントローラ、ゲートウェイ、プレゼンタという要素については
10章分くらいで説明がされているのでパターン自体の概要を知るためにも良いと思います。
（「10章分くらい」としているのは対象に入るかどうか個人の感覚によるのでおおよそです）

ただ、ユースケースの入出力のアダプタをコードレベルで詳細には説明を行なっていないので、
コードレベルの設計となると自分で実践しながら覚えていくことになると思います。

2018-09-02

GoのカバレッジをCoberturaを使ってJenkinsで表示する

Golang Jenkins

JenkinsでGoのカバレッジをグラフィカルに出したいなと思い調べてみたら
gocover-coberturaというライブラリを使うと実現できるということだったのでまとめてみました。

前提

Go 1.10.3
Jenkins 2.121.3
- Go plugin 1.2
- Cobertura Plugin 1.12.1
dep 0.5.0

概要

CoberturaはJava用のカバレッジツールなのでGoで使うためには変換が必要になります。
パイプラインスクリプトの大まかな流れとしては下記です。

まずmakeのスクリプト内部でカバープロファイルを取得します。
取得したカバープロファイルをgocover-coberturaでCobertura用のXML変換にします。
最後に変換したXMLをCobertura Pluginでグラフィルカルに表示します。

make

go testでカバレッジを取得しようとした時にパラメータを指定しないと
テストが実行されたファイルだけが対象となってしまいます。
この状態でカバレッジを集計するとカバーしているパッケージは必ず100%になってしまうため本来欲しいものが取得できません。

-coverpkgというパラメータを指定するとその対象のディレクトリが全てカバレッジの計算対象になります。
なので今回は-coverpkgを使って本当に欲しいカバレッジを取得するようにしています。

テスト時のコマンドは下記のようになります。

go test -coverprofile=${カバープロファイル} -coverpkg=${対象ディレクトリ} ${対象ディレクトリ}

実際に実行されるコマンドは下記のようになります。

go test -coverprofile=bin/cover.out -coverpkg=./example/... ./example/...

binディレクトリの下はGitの管理対象外ディレクトリとしていることを想定しています。
こういうのはどこに置けばいいのかわからなかったのですが他に適切な場所があればそちらに置くのが良いです。

gocover-coberturaでXMLに変換

gocover-coberturaを使ってカバープロファイルをXMLに変換します。
パイプラインスクリプトでは毎回gocover-coberturaを取得するようにしています。

stage("Prepare") {
    steps {
        sh 'go get -u github.com/t-yuki/gocover-cobertura'
    }
}

makeコマンドで取得したカバープロファイルを読み込ませます。

sh "gocover-cobertura < bin/cover.out > bin/cover.xml"

ここはgocover-cobertura公式のサンプルコマンドとほぼ同じです。

Coberturaプラグイン

最後にCobertura Pluginを使ってグラフィルカルに表示します。

cobertura (
    autoUpdateHealth: false,
    autoUpdateStability: false,
    coberturaReportFile: 'bin/cover.xml',
    conditionalCoverageTargets: '70, 0, 0',
    failUnhealthy: false,
    failUnstable: false,
    lineCoverageTargets: '80, 0, 0',
    maxNumberOfBuilds: 0,
    methodCoverageTargets: '80, 0, 0',
    onlyStable: false,
    zoomCoverageChart: false
)

coberturaReportFileに先ほど変換したXMLファイルのパスを指定するだけです。

生成されたXMLの内容

CoberturaはJava用のツールであるため変換されたXMLもJavaに則した内容になっています。
Javaはクラスベースなのでカバレッジの取得もクラスがある前提で集計されます。

Goの場合はクラスがないのでどういう集計をしているのだろうかと思って結果を見てみたところ
1構造体=1クラス、レシーバのない関数は-というクラスに属するものとして集計しているようです。
これはgocover-coberturaの仕様のようです。

まとめ

といことでJenkinsでカバレッジを取得できるようになりました。
-coverpkgの情報をなかなか見つけられずに苦労しましたが
最終的に出来上がったスクリプトでは難しいことは特にしていないと思います。

わかってしまえばお手軽にできるので簡単にカバレッジ取得できますね。

2018-09-01

Go/depを使ったJenkinsビルド

Golang Jenkins

GoのソースをJenkinsからでビルドする方法をまとめてみました。
depを使って依存性を解決した上でビルドというのがなかなか見つけられなかったので色々と試行錯誤してみました。
世の中のプロダクト環境ではもっと良い方法があるのかなとは思いますが・・・

前提

Go 1.10.3
Jenkins 2.121.3
- Go plugin 1.2
dep 0.5.0

私がGo初心者なのでGo界隈で常識的なやり方などは一切知りません。
そんなかで試行錯誤したやり方という前提でお読みください。

参考サイト

Jenkinsでgo言語のプロジェクトをCIする方法を調査した - ぐるっとぐりっど

概要

やりたいこととしてはdepで依存性を解決してビルドなのですが、
同じJenkinsに複数のGoプロジェクトがあっても大丈夫なようにしたい。
というのがやりたないという感じでやっています。

そのため、GoのバージョンとGOPATHはプロジェクトごとに変えられるようにしています。

勉強用のコードで作ったものはこちらです。
（masterを参照すると将来的に変わりそうなので動いた当時のコミットです）

環境変数

環境変数の設定処理は下記。

    environment {
        PROJECT_NAME="go-crud-practice"
        TARGET_GO = tool name: 'Go.1.10.3', type: 'go'
        GOPATH = "${JENKINS_HOME}/workspace/${env.JOB_NAME}/GOPATH"
        GOBIN = "${GOPATH}/bin"
        CHECKOUT_DIR = "GOPATH/src/github.com/gloryof/${PROJECT_NAME}"
        PATH= "$PATH:${GOBIN}:${TARGET_GO}/bin"
    }

TARGET_GOはGo pluginから指定したバージョンのGoのパスを参照しています。
GOPATHにはプロジェクトごとのパスを設定します。
上記で設定した内容をPATHに指定してビルド時に使えるようにしています。

CHECKOUT_DIRにはGOPATHの中のdep準拠のディレクトリに構成になるようなパスを設定します。
このCHECKOUT_DIRはチェックアウト処理の時に使います。

depのインストール

depはPrepareステージというものを作成して毎回インストールしています。
この書き方だとdepのバージョン変わるので指定したバージョンの取り方は調べないと思いつつやってないです・・・

stage("Prepare") {
    steps {
        sh 'go get -u github.com/golang/dep/...'
    }
}

チェックアウト

checkout scmだと指定したパスにチェックアウトする方法を見つけられなかったので、
色々とパラメータを設定して指定したパスにチェックアウトしています。

stage("Checkout") {
    steps {
        checkout([
            $class: 'GitSCM',
            branches: [
                [name: '*/master']
            ],
            doGenerateSubmoduleConfigurations: false,
            extensions: [
                [$class: 'RelativeTargetDirectory', relativeTargetDir: "${CHECKOUT_DIR}"]
            ],
            submoduleCfg: [],
            userRemoteConfigs: [
                [url: 'https://github.com/gloryof/go-crud-practice']
            ]
        ])
    }
}

extensionsのRelativeTargetDirectoryを使って指定したパスにチェックアウトします。
relativeTargetDirに先ほどの環境変数で設定したパスを指定します。

Jenkinsのプロジェクト設定

おそらく普通にパイプラインをチェックアウトするでも動くと思いますが、
追加処理のSparse Checkout pathsにパイプラインスクリプトのパスを設定しています。

Sparse Checkout pathsを指定するとパイプライン実行前のチェックアウトは
その指定したパスだけをチェックアウトするようになるのでファイルが少なくなります。

ビルド

あとはビルドでmakeコマンドを実行するだけです。
dirでワーキングディレクトリを変更しないと動きません。

stage('Build') {
    steps {
        dir("${CHECKOUT_DIR}") {
            sh "make"
        }    
    }
}

まとめ

個人的には実戦でも使えるクオリティのスクリプトができてんじゃないかなと思います。
将来的にJenkinsにdep プラグインが出てくればこういうの不要になりそうな気がしますが。

2018-08-18

RDB技術者のためのNoSQLガイドを読み終わりました

書評

RDB技術者のためのNoSQLガイドを一通り読み終えたので書評です。

RDB技術者のためのNoSQLガイド｜書籍情報｜秀和システム

評価

★★★★★★★☆☆☆（7/10）
評価の目安はこちら

オススメできる人

NoSQLにはどのようなものがあるか知りたい人

オススメできない人

NoSQLの特定ソフトウェアの詳細を知りたい人

感想

NoSQLをタイプごとにどのようなものか、
メリットが何か、適した場面はどこかなどが説明してあります。
単純な機能だけではなく、性能拡張/高可用/運用と言った非機能面についても説明されています。

私自身はRDB（主にPostgreSQL）がメインだったので、
RDBとNoSQLの対比というのはとても参考になりました。
ただし、この本が執筆されたタイミングが2015年12月ということもあり
現時点でのRDBとNoSQLの対比をすると変わってくるところも存在しそうです。

RDB側しか情報収集していませんがJSON/レプリケーションといったところは
2016年以降でサポートが強くなっていると思うので当時と現時点では状況が異なると思っています。

それでもNoSQLの詳細を知らない私にとっては参考になった一冊でした。

2018-07-28

PostgreSQL 10 Administration Cookbookを読み終わりました

書評

PostgreSQL 10 Administration Cookbookを一通り読み終えたので書評です。

PostgreSQL 10 Administration Cookbook | PACKT Books

評価

★★★★★★☆☆☆☆（6/10）
評価の目安はこちら

オススメできる人

PostgreSQLを使って運用する人

オススメできない人

PostgreSQLを使って開発のみをする人
PostgreSQLの公式ドキュメントを読破した人

PostgreSQL公式ドキュメントが充実しているので
公式ドキュメントを読破している人にとっては知っている内容が多いかもしれません。
（そういう人はかなり少ないと思いますが・・・）

感想

PostgreSQLで運用していて発生した問題などに対して
どうすれば解決できるかというレシピ的なものがまとめられています。
運用ししててリファレンス的に使うのがちょうど良さそうだと思いました。

下記のような部分は他の本では書かれていることは少ないと思います。

モニタリング
パフォーマンス解析
データ使用量調査
バックアップ
バックアップ/リカバリ
レプリケーション

そういった部分が書かれていたのは個人的に勉強になったなと思います。

実行時間がかかっていてCPUやIOを使いすぎているプロセスの止め方や
巨大なテーブルに対して早くだいたいのレコード数を知るための方法など
結構コアなところも書いてあります。
コアな操作方法を知るためには良い本かなと思いました。

2018-06-09

スモール・リーダーシップを読み終わりました

書評

スモール・リーダーシップを一通り読み終えたので書評です。

スモール・リーダーシップチームを育てながらゴールに導く「協調型」リーダー（和智右桂）｜翔泳社の本

評価

★★★★★★★☆☆☆（7/10）
評価の目安はこちら

オススメできる人

リーダーを目指す人

現在数人のチームをまとめている人、または、今後まとめる人にとっては良い本だと思います。

オススメできない人

カリスマリーダーを目指す人

この本はタイトルの通り小さいチームを率いるリーダーのための本です。
カリスマリーダーを目指す人にとってはタイプが異なるので参考にならないかもしれません。

感想

サーバントリーダーを目指したいなと思って日々行動をしています。
ただ、Webの記事を少し読んだりするだけで体系的に学んだことはないなと思い購入しました。

内容としてはどうやってチームを良くしていくか。
そして、リーダーとしてはどういったことを心がけ実践していくのか。
というのが書かれていて非常に参考になりました。

表紙に「技術」でチームを回そうと書かれている通り、本の内容は具体的な手法ベースで書かれています。
「明日から早速行動に移してみよう」ということが可能な内容になっていると思います。

私にとってはとても共感できる内容でした。
その中で実行時に求められる責任について
「目標を達成しようと最善を尽くすことであり、その過程と結果に対して説明する義務を果たすこと」
というのは一番心に残った内容でした。

サーバントリーダーを目指す人にとっては非常に参考になる本だと思います。

2018-05-20

ネットワーク超入門講座を読み終わりました

書評

ネットワーク超入門講座を一通り読み終えたので書評です。

SBクリエイティブ:ネットワーク超入門講座第4版

評価

★★★★★☆☆☆☆☆（5/10）
評価の目安はこちら

オススメできる人

ネットワーク構築の初心者
ネットワークについて基本的な知識をつけたい人

オススメできない人

ネットワーク構築に携わらない人

感想

ネットワークの知識が足りていないなと思い復習するために購入しました。
私個人としては新しい知識というものはなかったものの
ネットワークに関わる部分の復習としては良かったなぁと思いました。

LANとWANの基本知識やセキュリティに関する部分などがあり
ネットワークに関する全体像を知るためには良い本だと思います。
また、「ネットワーク超入門講座」という名の通り
初心者にもわかりやすい説明になっているという印象を受けました。

ネットワークに関する初心者向けの本としては良書だと思います。