hijikitaroのブログ

しがないSIerとして、日々プロジェクトを管理し、システムを育て、日々お子を見守り育てる中での出来事や学びを淡々と書いています。

読書記録まとめ(2020年2月)

月末に読んだ本をまとめていく習慣をつけようと思い、ブログを書いていきます。

読んだ本

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

継続的デリバリーに対する、構成管理、インテグレーション、テスト、デプロイメント といったソフトウェアを早く品質よくリリースしていくための考え方や手法が網羅的に書かれており、かなりためになる本でした。プロジェクトが始まる前に開発部隊だけでなく、プロジェクトマネジメントの人も含めて、チームとして知っておくとみんなが幸せになれるのではと感じています。 (補足:過去のプロジェクトで、構成管理を不具合用branch、改修用branchがある構成にしており、この考え方自体が継続的に合わないと知り、やっちまったなと思いました。あの時も継続的にリリースされることを見越して考えていたんだけどな・・・)

どの本がよかったか

  1. 継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

おわりに

本を読むよりも会社の研修教材を優先してやっていたので、2月は全然本を読んでいませんでした。

学び記録まとめ(2020年2月)

2020年2月のなんやかんやのやったことを羅列するブログ。

仕事関連でやったこと

  • 開発品質改善
    • 開発品質
      • コードインスペクション(FindBugs、SonarQube etc)
    • 開発標準

勉強(IT)でやったこと

  • Ant
  • Findbugs・SpotBugs
  • SonarQube
  • windows bat
  • Java(8に関する超入門 Lambda)
  • DevOps 超入門(考え方とプロセス)
  • Cloud 超入門(考え方や効果・製品)

勉強(英語)でやったこと

  • リーディング(英語の記事やら英語の社内教材など)
  • リスニング(Netflix

おわりに

テーマが絞れていない感があり、雑多にやりすぎている気がするので来月以降修正をしていこうと思います。直近、プロジェクトに関係する Java を中心に CI/CDツールも勉強していければと考えています。(もしかしたら OpenShift の勉強もやっていくかも)

bat で 指定ディレクトリ分 FindBugs を繰り返す

最新技術を磨くぞ、と意気込んで転職したわけだったんですが、隔離されたインターネットもつなげない環境にいるため、

ちまちまAnt作ったり、bat作ったりと昔ながらのやり方でいろいろ自動化?を試みているのですが、

そのためにちょろっと作ったものをせっかくなので残しておこうと思います。

(5年前ぐらいに同じことをやったものの当時はブログも何もしていなかったので、今回は忘れないように・・・残します。)

やりたいこと

  • 対象のディレクトリごとに FindBugs を自動で実行する。(実際には1000個ぐらいのJavaプロジェクトがあるので、Eclipse でちまちまやりたくない)
    • 対象ディレクトリは機能のカテゴリで頭文字が決まっている。
    • 対象ディレクトリ配下のクラスファイルの配置場所は同じ。

やったこと

以下が作成した bat 。

REM FindBugsを指定フォルダ分実行
@setlocal enabledelayedexpansion

set DIR_CATEGORY=ant fin test

REM アプリカテゴリ単位にfindbugsを実行
for %%f in (%DIR_CATEGORY%) do (
    echo %%f
    REM ディレクトリ = ant
    for /D %%A in (%%f*) do (
        echo %%A
        
        REM findbugs実行
        REM param:
        REM   -textui          テキストユーザインターフェース
        REM   -projectName  プロジェクト名
        REM   -low          すべてのバグランクを対象
        REM   -effort:max   精度が高く、より多くのバグを検出する
        REM   -output       アウトプットパス(batファイルと同じディレクトリ)
        REM   -xml:withMessages       出力形式XML、かつ、日本語メッセージあり
        REM   最後のパラメータは解析対象フォルダパス
        findbugs -textui -projectName %%A -low -effort:max -output f_%%A.xml -xml:withMessages %%A"\target"
    )
)

おわりに

FindBugsコマンドラインのオプションが何となくわかったので、やれてよかったと思います。 ただ、CI/CDを学びながらDevOpsを理解し、開発者がより生産的で知的な開発が行える文化や環境を作っていきたいと思っていたのに、そのための技術が世の中にはたくさんあるというのに・・・

実務ではこんなレベルのことしかできない状況に若干悲しみを覚え始めている今日この頃。

というわけで、CI/CDやDevOpsに関係する勉強会に参加し、社外や今のPJ以外のコミュニティに入り、心の平穏を保っていこうと思いました。

いまさら需要が全然ないと思うけど、Ant で FindBugs を実行する方法

いろいろあって Ant + FindBugs で性的解析をすることになったので、ちょっとした実行方法をメモします。

環境

ANT_ROOT=C:\tools\apache-ant-1.10.7
JAVA_HOME=C:\Program Files\Java\jdk1.8.0_221

手順

Ant のインストール

www.kkaneko.jp

最新のApache Ant(Java8以降対応のバージョン)をダウンロードし、展開したフォルダをCドライブ直下のtoolsフォルダに配置する(toolsフォルダがなければ自分で作成する)。

次に、システム環境変数に下記を追加する。

  • 「ANT_ROOT」:「C:\tools\apache-ant-1.10.7」
  • 「path」:「C:\tools\apache-ant-1.10.7\bin」

最後に、コマンドプロンプトで設定されているか確認する。

>ant -v
Apache Ant(TM) version 1.10.7 compiled on September 1 2019
Trying the default build file: build.xml
Buildfile: build.xml does not exist!
Build failed

FindBugs のインストール

下記リンクから「findbugs-x.x.x.zip」をダウンロードする。

findbugs.sourceforge.net

次に、ダウンロードしたzipを展開し、Cドライブ直下のtoolsフォルダに配置する。

次に、Ant から FindBugs を使用できるように、

「C:\tools\findbugs-3.0.1\lib\findbugs-ant.jar」を「C:\tools\apache-ant-1.10.7\lib」にコピーする(移動ではなく、コピー)。

※下記リンクに手順は記載されている。

findbugs.sourceforge.net

※システム環境変数に設定をしなくても build.xml 上で設定は可能なため、今回は実施していない。

build.xml の作成

build.xml を作成するフォルダは、FindBugs を実行したいプロジェクト配下に配置する(複数のプロジェクトが存在する場合は今回は除く)。

xml の構成は jarファイル作成→FindBugs実行としている。FindBugs を実行するために必要な設定は以下と認識している。

FindBugs を Ant で実行する方法は下記リンクに記載されている。

findbugs.sourceforge.net

<?xml version="1.0" encoding="UTF-8" ?>
<project name="FindBugsTest" default="makeJar" basedir=".">

    <!--
        定数の定義。
        build.xml上で使用する定数を定義する。
    -->
    <!--
        ビルドのベースディレクトリ。
        何もなければ${basedir}を使っても問題ありませんが、
        他プロジェクトのbuild.xmlからこのbuild.xmlのタスクを呼び出したとき、
        basedirがずれてしまうことがあるので、別に定義しておく。
    -->
    <dirname property="base" file="${ant.file}"/>

    <!-- JARファイル名 -->
    <property name="jarname" value="FindBugsTest" />

    <!-- ビルド成果物ディレクトリ -->
    <property name="dir.target" value="target" />
    <property name="dir.target.classes" value="${dir.target}/classes" />

    <!-- srcディレクトリ -->
    <property name="dir.src" value="src" />

    <!-- ソースファイルエンコード -->
    <property name="src.enc" value="UTF-8" />

    <!-- JARファイル作成(開発用) -->
    <target name="makeJar" description="jarファイル作成">
        <antcall target="clean"/>
        <antcall target="compile"/>
        <echo message="JARファイルの作成" />
        <jar basedir="${dir.target.classes}" destfile="${base}/${dir.target}/${jarname}.jar" />
    </target>

    <!-- ビルド成果物削除 -->
    <target name="clean" description="ビルド成果物削除">
        <delete dir="${dir.target}" />
    </target>

    <!-- コンパイル -->
    <target name="compile" description="コンパイル">
        <echo message="コンパイルを開始します。" />
        <mkdir dir="${dir.target.classes}"/>
        <javac 
            srcdir="${dir.src}"
            destdir="${dir.target.classes}"
            encoding="${src.enc}"
            source="1.8"
            target="1.8"
            includeAntRuntime="false"
            debug="true"/>
    </target>

    <!-- FindBugs実行 -->
    <!-- FindBugsのタスクの実行に使用されるクラスを指定する。 -->
    <taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask"/>

    <!-- FindBugsのHOMEディレクトリを指定する。 -->
    <property name="findbugs.home" value="C:\tools\findbugs-3.0.1" />
    
    <!-- FindBugsのタスクを設定する。 -->
    <target name="findbugs" depends="makeJar">
        <findbugs home="${findbugs.home}"
            output="html"
            outputFile="./findbugs-test.html">
            <auxClasspath path="${basedir}/**/*.jar" /> <!--分析の対象にはしたくないjar(クラスパス)-->
            <sourcePath path="${basedir}/src/app/findbugs/test" /> <!-- 解析対象のソース配置場所 -->
            <class location="${base}/${dir.target}/${jarname}.jar"/> <!-- 解析対象のJavaプログラム(正規表現使用可能) -->
        </findbugs>
    </target>

</project>      

Ant の実行

build.xml ファイルが配置されているプロジェクトまで移動し、下記コマンドを実行する。

ant <target name>

以上で、jar のビルドと FindBugs が実行される。

おわりに

とりあえず、チュートリアル的なことはできたので、実務レベルでやっていこうと思います。また、これを機にビルドツールを自分なりにまとめてみると今後役立つのではと感じました。あと、自分はアプリのコーディングよりもビルドのコーディングのが楽しいと感じる傾向にあるかもしれないということがわかりました。

というわけで、次からはローカルPCでやらずに、Docker 上でやってみようと思っていたりしています。

読書記録まとめ(2020年1月)

月末に読んだ本をまとめていく習慣をつけようと思い、ブログを書いていきます。

読んだ本

ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略

ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略

ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略

感想はこの前書いたものがあるので、そちらを見てください。

hijikitaro.hatenadiary.com

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

もう一度しっかりと読み直して読書記録としてまとめようと思っている1冊になります。

アーキテクチャの考え方は昔から変わらないということが感じられる一冊と感じました。今も昔もいかに書く機能やシステムが密結合にならない、影響を与えないように考えていくことが重要であり、いつも開発のサイクルを早くなるように心がけていく必要があると感じさせてくれる内容になります。また、とても印象的だったことが、アーキテクトの役割として、可能な限りアーキテクチャの決定を遅らせることという言葉で、今までの開発経験だとアーキテクチャをわりと早い段階で決めることが多く(見積や人員確保のためなど要因はいろいろ)、アーキテクトの役割や開発の考え方を考え直すきっかけになりました。もう一度読み直してこの部分を重点的に理解していきたいと思っています。

やさしく学ぶ 機械学習を理解するための数学のきほん ~アヤノ&ミオと一緒に学ぶ 機械学習の理論と数学、実装まで~

本当にやさしく学べる本です。

機械学習に関する数学を順番にわかりやすく、とっつきやすく説明してくれているので理解が進み入門書として適していると感じました。さらに、Python のサンプルコードが書いてあるので、実際に試しながら感覚的に理解していけるため助かりました。

ちなみに、コードの実行はローカルPCではなく、「Google Colaboratory」を利用しました。 (一応ローカル環境には、Anacoda で Python 環境はあります。)

見て試してわかる機械学習アルゴリズムの仕組み 機械学習図鑑

見て試してわかる機械学習アルゴリズムの仕組み 機械学習図鑑

見て試してわかる機械学習アルゴリズムの仕組み 機械学習図鑑

機械学習アルゴリズムをふとした時に確認するのに、便利な一冊です。

この本もサンプルコードがついているので、ちょっとしたときに試せるので便利だと感じています。実行するのは、やっぱり「Google Colaboratory」。

さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0

この本を買うことで実施できる強み分析が有効です。しっかり自分らしい強みが出てきました。とにかく情報収集して新しい知識を身に着けたい欲にまみれた人間らしいです。

質問力

質問力 ちくま文庫(さ-28-1)

質問力 ちくま文庫(さ-28-1)

最近改めて質問が苦手なので読んでみました。(研修時に全然質問できず、役に立っていない感があるので)

質問を4象限で意識して用意するなどちょっとした考え方を知ることができました。が、まだまだ活かすことができずに質問は苦手なままになります。この本も再度読み直してまとめておく必要がありそうです。

英文読解入門基本はここだ!―代々木ゼミ方式 改訂版

英文読解入門基本はここだ!―代々木ゼミ方式 改訂版

英文読解入門基本はここだ!―代々木ゼミ方式 改訂版

  • 作者:西 きょうじ
  • 出版社/メーカー: 代々木ライブラリー
  • 発売日: 2005/05/01
  • メディア: 単行本

英語を学習してきた中で、単語はだいぶ覚えてきたが、英文を解釈する力がなさすぎる(精読ができない)ことがわかってきたで読んでみました。 内容としては、英文の捉え方や特徴が整理されていてかなり勉強になる気がします。ただ、まだ基礎が定着していないため、一度では理解することが難しい本な気もします。この本が理解できれば、精読力は抜群にあがると思われる一冊です。

The Coldest Place on Earth Level 1 Oxford Bookworms Library (English Edition)

The Coldest Place on Earth Level 1 Oxford Bookworms Library (English Edition)

The Coldest Place on Earth Level 1 Oxford Bookworms Library (English Edition)

初めての洋書になります。本自体はかなり簡単でシンプルな英語で書かれているため、英語超初心者でもがんばれば物語を追っていける本になります。

ただし、まだまだ英語力は低いので、間違えて理解しているケースが多く、話が途中でおかしくなることは何度もありました。

Leonardo da Vinci Level 2 Oxford Bookworms Library (English Edition)

Leonardo da Vinci Level 2 Oxford Bookworms Library (English Edition)

Leonardo da Vinci Level 2 Oxford Bookworms Library (English Edition)

洋書の2冊目になります。

内容自体は、ダヴィンチの概要がざっくりわかる内容になります。とにかく、多岐にわたる才能をもった天才だったことと、常に疑問を唱え続ける、好奇心おばけなダヴィンチのことが伝わってくる本になります。

A Christmas Carol (Oxford Bookworms Library. Classics. Stage 3)

A Christmas Carol (Oxford Bookworms Library. Classics. Stage 3)

A Christmas Carol (Oxford Bookworms Library. Classics. Stage 3)

洋書の3冊目になります。

これはまだ読み中です。

どの本がよかったか

  1. ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略
  2. Clean Architecture 達人に学ぶソフトウェアの構造と設計

おわりに

1月は正月休みということもあり、結構本は読んだと感じています。しっかりと読書記録をつけていかないとポンコツ脳みそでは全然思い出せない・ふんわりしか思い出せないことが多かったので、数行でもよいので読書記録としてまとめていきたいと思います。

仕事も始まって大変になると思いますが、来月以降も続けていきたい、いや、続けていきます。

学び記録まとめ(2020年1月)

2020年1月の技術やら英語やらなんやかんやのやったことをまとめてみます。

仕事関連でやったこと

  • 1月の経歴まとめ
  • 開発方法のまとめ

IT関連でやったこと

英語関連でやったこと

おわりに

箇条書きにしただけなので、来月以降は詳細に書いていきます。

やったことをしっかり自分の知識として身につけていけるような工夫をしながら、まとめていくようにしていきます。(だいぶさぼっていますね)

SonarQube について調べもの

SonarQube を使用し、コードの品質向上を試みることになった + 初めて触るので、勉強がてら調べたことをまとめておきます。

SonarQube とは

https://www.sonarqube.org/

ざっくり言うと、自動コードレビューツールになります。

バグ、脆弱性、Code Smells(※1) を自動で検出してくれるコードインスペクションツール。

以下が簡単な特徴

  • 多数の言語に対応(JavaPythonCOBOLなどの新旧含めて)
  • 様々な問題を検出(バグ、Code Smells)
  • セキュリティチェック
  • etc

※1:

qiita.com

何ができるのか

以下が公式のドキュメント(英語)。 これを読みながら理解する必要がありそう。

https://docs.sonarqube.org/latest/

  • 対応言語

主要な言語は対応している。(Webで使用される言語は大半網羅されていると思われる。)

https://docs.sonarqube.org/latest/analysis/languages/overview/

どうやって環境を作るのか

以下記事にまとめられている。

dev.classmethod.jp

※Dockerイメージも存在するため、Docker が利用できるのであればそちらを使うとよいと思います。(確実に楽だと思います。)

おわりに

検知できるバグの詳細や見方などをまとめて実業務で活かしていきたいと思います。せっかくなので、手作業は極力なくして、日々の開発サイクルに取り込めばもう少しコードの品質が上がるのではと思われます。

最近、人が指摘するよりシステムが指摘した方が聞く気がする気がしています。

参考

qiita.com