24 Sep 2017, 13:39

Spock で モック を interfaceを用意せずにつくる方法

はじめに

前回、spockの mock 機能を利用するために、interfaceを用意していた。

というのも、interfaceからでないとMockを作成できないと思っていたからだ。

しかし、interfaceを用意しなくても、classからモックを作成できることがわかったので、紹介。

byte-buddy

class からモックを作ろうとすると、以下のようなエラーがでる。

org.spockframework.mock.CannotCreateMockException:Cannot create mock for class sample.Calculator. Mocking of non-interface types requires a code generation library. Please put byte-buddy-1.6.4 or cglib-nodep-3.2 or higher on the class path.

注目すべきは、Please put byte-buddy-1.6.4 or cglib-nodep-3.2 or higher on the class path.

なんだ、byte-buddyとは?ということで、検索。

どうやら、コードを自動生成するようなライブラリらしい。早速インストール。gradleをつかっているので、以下を build.gradleのdependencies

に追加。他のビルドツールでの追加方法は、byte-buddyのサイトを参照してください。

testRuntime "net.bytebuddy:byte-buddy:1.7.5"

すると、interfaceを実装していないクラスからでもMockがつくれた!

実列

以下のクラスのモックを作る。

class Calculator {

    int add(int a, int b) {
        return a + b
    }
}

テストコードは以下。

def "interfaceなしでMockをつくる" () {
    setup:
    def calc = Mock(Calculator)
    calc.add(_, _) >> 4

    expect:
    calc.add(1,2) == 4
}

これを走らせると、テストが成功する。

何が起こっているのかわからないけれども、おそらくクラスからインタフェースを自動生成しているのかな?とりあえず、便利になった。

コードは以下です。

今日はここまで。

24 Sep 2017, 08:48

Javaでsetter/getter自動生成するLombokが便利。IntelliJ+gradleでの設定

はじめに

Lombokという Javaのライブラリが便利。

アノテーションを使うことで、getter, setter, toStoring, コンストラクタなどの、

定型的なコードを自動生成することができる。

gradleでのインストール

gradleでは、build.gradleのdependenciesに以下の行を追加する。

dependencies {
    compileOnly 'org.projectlombok:lombok:1.16.18'
}

IntelliJ IDEAでの設定

まずは、プラグインを入れる。ツールバーのFile -> Preferences -> Plugins から、

Lombokを検索して、インストール。

次に、コンパイル時に、アノテーションからコードを自動生成する機能を有効にする。

Preferences – Build, Execution, Deployment – Compiler – Annotation Processors を開き

Enable annotation processing をチェック。

ここまでできたら、IntelliJを再起動。

使用例

いろいろと便利な機能があるのだが、つまみぐいして紹介。

@Getter/@Setter

このアノテーションを使うと、getter/setterを自動生成してくれる。

class Parson {
    private @Getter @Setter String name;
}
  • getName()
  • setName()

@ToString

このアノテーションを使うと、toStringを自動生成してくれる。

@ToString
class Parson {
    private @Setter String name;
}

Person(name=mikan) とか表示される。

@Data

getter/setter/コンストラクタ/toString/equals/hashCode 自動生成。すごい。

@Data
class Group {
    private String name;
}

@AllArgsConstructor

フィールドを持つ変数を引数にするコンストラクタを自動生成。

@AllArgsConstructor
class Group {
    private String name;
    private int id;
}
  • Group(String, int)

24 Sep 2017, 05:57

Spockでモックとスタブを使ってJavaコードをテストする

はじめに

前回の続きです。

前回は、基本的な文法を確認しました。今回は、モック機能を使ってみます。

テスト対象コード

想定としては、MockSampleが自分が開発しているコード。MessageManagerが他人が開発しているコードとします。

MessageManagerクラスの開発は遅延しているので、インタフェースだけ先に提供されているものとします。

こんなとき、自分が作ったMockSampleクラスをMessageManagerの依存関係をうまく扱ってテストすることを目指します。

  • MockSample.java
package sample;

public class MockSample {
    private MessageManager mgr;

    public void setManager(MessageManager mgr) {
        this.mgr = mgr;
    }

    public void sendMsg(String msg) {
        mgr.send(msg);
    }

    public int sendMsg2(String msg) {
        return mgr.send2(msg);
    }
}
  • MessageManager.java
package sample;

public interface MessageManager {
    void send(String msg);
    int send2(String msg);
}

テストコード

モックとスタブの言葉の定義は人それぞれあって混乱するのだけれども、ここでは

  • モック: 呼びだされたときに与えられるパラメータチェックと呼び出し回数をチェックするダミークラス
  • スタブ: 呼びだされた時に戻り値を返すダミークラス

とします。

モック

まずは、モックから。Mockを生成するには、

def mgr = Mock(MessageManager)

とするか、

MessageManager mgr = Mock()

で宣言します。

import sample.MessageManager
import sample.MockSample
import spock.lang.Specification

class MockSampleSpec extends Specification {

  def "呼び出し引数をチェック(Mocking)"() {
      setup:
      def sample = new MockSample()
      def mgr = Mock(MessageManager)
      sample.setManager(mgr)

      when:
      sample.sendMsg("hello")
      sample.sendMsg("hello")

      then:
      2 * mgr.send("hello")
  }
}

以下で2回呼び出しを期待して、呼び出し引数は”hello”を期待しています。

2 * mgr.send("hello")

スタブ

次にスタブです。以下の宣言で、戻り値をオブジェクトに指定します。

mgr.send2(_) >> 1
def "戻り値を返す(Stubbing)" () {
    setup:
    def sample = new MockSample()
    def mgr = Mock(MessageManager)
    mgr.send2(_) >> 1
    sample.setManager(mgr)

    expect:
    sample.sendMsg2("hello") == 1
}

例外をチェックするテストコード

戻り値の代わりに例外をスタブで発生させることもできます。

def "例外が発生したことを確認する" () {
    setup:
    def sample = new MockSample()
    def mgr = Mock(MessageManager)
    mgr.send(_) >> {throw new IllegalArgumentException()}
    sample.setManager(mgr)

    when:
    sample.sendMsg("hoge")

    then:
    thrown(IllegalArgumentException)
}

また、なにも例外が発生しなかったことを確認することもできます。

def "例外が発生しないことを確認する" () {
    setup:
    def sample = new MockSample()
    def mgr = Mock(MessageManager)
    sample.setManager(mgr)

    when:
    sample.sendMsg("hello")

    then:
    noExceptionThrown()
}

コードはgithubにもあげています。

参考

今日はここまで!

21 Sep 2017, 13:54

Spock をつかってJavaコードをテストしてみた

はじめに

仕事で spockをつかうことになりそうなので、まずはHello, World的な簡単なサンプルを実行することにしました。

環境構築

環境情報

  • JDK 1.8
  • IntelliJ IDEA 2017.2.4
  • spock 1.1(groovy2.4)

IntelliJで プロジェクト作成

IntelliJ のツールバーより、

  • [ファイル] -> [新規] を選択。
  • Gradleプロジェクトを選択。
  • Java, Groovyにチェックを入れる。

あとは、デフォルトのままにOKを押していく。

build.gradleの修正

spockをダウンロードするようにbuild.gradleを修正。

version '1.0-SNAPSHOT'

apply plugin: 'groovy'
apply plugin: 'java'

sourceCompatibility = 1.8

repositories {
    mavenCentral()
}

dependencies {
    compile 'org.codehaus.groovy:groovy-all:2.3.11'
    testCompile "org.spockframework:spock-core:1.1-groovy-2.4"
}

code

テスト対象コード

以下のクラスをテストします。src/main/java/sample/Calculator.java

package sample

class Calculator {
    int add(int a, int b) {
        return a + b
    }
}

テストクラス

以下のテストクラスを用意します。 test/groovy/CalculatorSpec

package spock

import sample.Calculator
import spock.lang.Specification

class CalculatorSpec extends Specification {

    def '足し算1'() {
        setup:
        Calculator calc = new Calculator()

        expect:
        calc.add(1,1) == 2
    }
}
  • setup: ・・・ 前処理でやりたいことを書く
  • expect: ・・・期待するテスト結果を書く == でAssertする。

CalculatorSpecを選択して、実行する。テストが成功します。

テストクラスその2

こんどはわざと失敗するテストを書いてみます。

def '足し算1'() {
    setup:
    Calculator calc = new Calculator()

    expect:
    calc.add(1,2) == 4
}

以下のようにわかりやすいエラー表示が出力されます。

Condition not satisfied:

calc.add(1,2) == 4
|    |        |
|    3        false
sample.Calculator@5e316c74

予想 :4

実際   :3

リファクタリング

前処理、後処理をまとめる関数が用意されています。

  • 前処理: setup(){}
  • 後処理: cleanup(){}
package spock

import sample.Calculator
import spock.lang.Specification

class CalculatorSpec extends Specification {
    def calc

    def setup() {
        calc = new Calculator()
    }

    def cleanup() {
        calc = null
    }

    def '足し算1'() {
        expect:
        calc.add(1,1) == 2
    }

    def '足し算2'() {
        expect:
        calc.add(1,2) == 3
    }
}

データ駆動テスト

where:を使うことで、データテーブルを使ったテストがかけます。

def "足し算:データ駆動テスト"() {
    expect:
    calc.add(a, b) == c

    where:
    a|b|c
    1|1|2
    2|3|5
    3|4|7
}

その他

コードはgithubにもあげています。

続き

今日はここまで!

18 Sep 2017, 02:24

Java本格入門(モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで)を読んだ

仕事でJavaをつかうことになった。

2年間Javaを使ってなかったので、忘れてしまった。

さびついた頭脳に磨きをかけるために、Java本格入門を読みました。アクロ本というらしい。

特徴

Javaの文法がコンパクトにまとまっている

Javaの文法を外観できます。

Java8まで対応しているので、ラムダ式やストリームまでカバーしています。

また、各Javaのバージョンごとの説明が詳しいです。

裏タイトル: 35歳からのJava入門

この本の裏タイトルは、35歳からのJava入門です。

世の中には、プログラマ35歳定年説というものがありますが、私はこれは嘘だと思います。

その根拠は、新人研修で習った知識で10年開発をやってきて、

時代の流れについていけなくなった人を指すのだと思います。

学び続ける人に定年はないです。そして、この本は、Java5,6を勉強して、

そのまま月日が経ってしまった、人に対する視点で書かれています。

新しくなったJava7,8の仕様がふんだんに紹介されています。

Javaの開発について書かれている

Javaの文法のみに終始している本とは違い、この本には、開発でつかうための知識が書かれています。

具体的には、(ビルド、javadoc, JUnit, FindBugs, Jenkins, JSON, Log…)

などの知識がてにはいります。実践的なJavaの入門書です。

ミッションクリティカルな配慮

秀逸なのは、例外についての説明や、並列処理についての説明です。

ここは、ミッションクリティカルなプロジェクトの経験を元に、とても丁寧に解説されています。

どこでどんな例外を捕捉するべきか、どんなライブラリを使うとスレッドせーフなプログラムになるか、

読んでいて知らないことが多いこのあたりの領域は目にウロコです。

感想

Java7,8の知識が知りたかったので、この本は当たり。

Java7,8ではこういう書き方があるということが書かれている。

自分は、一応 Java8 SE Silverの資格と2年間のJavaの開発経験があるので、

初心者ではない。そんな自分にとっては優しすぎる本は物足りない。

この本は、初心者以上の中級者をターゲットにして書かれているので、

自分にはちょうどよい難易度だった。

また、Java8で追加されたラムダ式やストリームについてもよくまとまっているので、

何度も参照して使いこなしたいところだ。

デザインパターンとか載っているけれども、これはおまけかな。

本格的に学ぼうとするなら、他の書籍をあたった方がいい。

とにかく、Javaに関する知識が盛りだくさんなので、

机の脇においておいて、困ったらいつでも参照できるようにしたい。

16 Sep 2017, 10:54

Java 8 で Command Pattern

はじめに

3年前の記事の補足です。

Java8で追加されたラムダ式でコマンドパターンを書き換えてみた。

かつては、Java 6を使っていたので、匿名クラスを利用して処理を実行と分離していた。

ポイント

  • インターフェースに 明示的に @FunctionalInterface アノテーションを追加する。
  • ラムダ式を使って、無名関数を渡す。

コード

01 Sep 2017, 09:56

Pythonではじめる機械学習(scikit-learnで学ぶ特徴量エンジニアリングと機械学習の基礎)を読んだ

O’Reilly Japan – Pythonではじめる機械学習 を読んだ。

副題: scikit-learnで学ぶ特徴量エンジニアリングと機械学習の基礎

動機

ニューラルネットを学ぶ、その前に

今まで、機械学習を通り越してディープラーニングの勉強をしてきた。

つまり基礎をすっ飛ばして、応用にいってしまったのだ。

自分の手法はただひとつ、ニューラルネットワークのみ!!

これでは、機械学習を勉強しているといえるのだろうか?

自分のなかで、疑問が湧き上がった。

本に付いている帯が印象的だった。

ニューラルネットワークを学ぶ、その前に! とのことだ。

これだ!ニューラルネットを学んで、

その後に行ってしまった自分にとってはこの帯はまさに心のうちをいい得ているものだった。

機械学習コンペの壁

ニューラルネットを学んで機械学習コンペに挑もうとしても、

前処理でなにをすればいいのかわからず手が出ない。

前処理は、特徴量エンジニアリングというらしいことを最近知った。

なので、前処理を詳しく解説している書籍はないものかと探していた。

この本の副題は、特徴量エンジニアリングと機械学習の基礎。これだ。

本の特徴

scikit-learnについての実践書

本書は、scikit-learnを使って機械学習をするための実践書だ。

機械学習の難しい理論は、でてこない。

そういう難解なものは、scikit-learnがすべて隠蔽してくれる。

この本では、機械学習アルゴリズムの利点と欠点、

ライブラリのパラメータの調整方法という実践的な知識が載っている。

また、ライブラリの使い方以外のことも書いてある。ズバリ、特徴量エンジニアリング。

どうやって、カテゴリカルデータやフラグデータをどうやってscikit-learnで扱うか、

数学はでてこない

本書は、微分積分、線形代数、確率論を何年も

学ぶことなく機械学習を使いたいという人のための特攻薬だ。

数学は一切出てこない。各機械学習の手法を言葉でわかりやすく説明している。

今、平行して機械学習のための数学の基礎固めを進めているのだけれども、

自分がなにをしたいかを考えた時、理論をガチガチにかためてなにもコーディングできないよりも、

Kaggleでバリバリデータ分析をしたいという思いがあった。

そこで、まずはscikit-learnで機械学習の概要を掴み、

Kaggleに積極的に挑み、理論は後付で学んでいく計画を立てた。

理論よりはコードファーストを目指す人にはオススメの本だ。

scikit-learnをつかった機械学習コンペ対策に

本の前半で教師あり学習と教師なし学習のアルゴリズムが解説されている。

残りの半分はなにが書いてあるかというと、

  • 特徴量エンジニアリング
  • モデルの評価方法
  • 交差検証、他
  • グリッドサーチを使ったパラメータチューニング方法
  • パイプラインを使った効率的なコーディング
  • テキストデータの扱い方

など、機械学習コンペに必要な技が細かく書いてある。

概要を説明したあと、scikit-learnをつかえばこんなふうにかけますよと、

実例を通して学ぶことができる。

学習できるアルゴリズムは豊富

たくさんのアルゴリズムが紹介されている。

それぞれ、どんな利点と欠点があるか、どういう場面で使うべきかが書かれている。

たとえば、教師あり学習のアルゴリズムを本書より抜粋。

  • 最近傍法: 小さいデータに関しては良いベースラインとなる。 説明が容易。
  • 線形モデル: 最初に試してみるべきアルゴリズム。 非常に大きいデータセットに適する。 非常に高次元のデータに適する。
  • ナイーブベイズ: クラス分類にしか使えない。 線形モデルよりもさらに高速。 非常に大きいデータセット、 高次元データに適する。 線形モデルより精度が劣ることが多い。
  • 決定木: 非常に高速。 データのスケールを考慮する必要がない。 可視化が可能で説明しやすい。
  • ランダムフォレスト: ほとんどの場合単一の決定木よりも高速で、 頑健で、 強力。 データのスケールを考慮する必要がない。 高次元の疎なデータには適さない。
  • 勾配ブースティング決定木: 多くの場合ランダムフォレストよりも少し精度が高い。 ランダムフォレストよりも訓練に時間がかかるが、 予測はこちらのほうが速く、 メモリ使用量も小さい。 ランダムフォレストよりもパラメータに敏感。
  • サポートベクタマシン: 同じような意味を持つ特徴量からなる中規模なデータセットに対しては強力。 データのスケールを調整する必要がある。 パラメータに敏感。
  • ニューラルネットワーク: 非常に複雑なモデルを構築できる。 特に大きなデータセットに有効。 データのスケールを調整する必要がある。 パラメータに敏感。 大きいモデルは訓練に時間がかかる。

また、教師なしアルゴリズムでは、以下のようなアルゴリズムが紹介される。

  • データセットの変換 ・・・PCA, NMF, t-SME
  • クラスタリング ・・・ k-means, 凝集型、DBSCAN

終わりに

機械学習の理論は難しいので、とりあえずscikit-learnを使って実際に動かすことで、

感覚をつかむというのはいい方法だと思う。

xgboostとかをはじめに知ってしまうと、理論は知らなくても万能感が得られたりする。

ただ、深く応用するためには理論も抑えていくことが大事なので、

自分はこれからはじめてのパターン認識を次に読んでいこうと思った。

29 Aug 2017, 14:28

ITエンジニアは勉強するべきか?の感想

おくればせながら、数カ月前にネットでバズッてた記事を見つけて興味深かったので、

思ったことを書いておく。

私は、エンジニアが業務時間外にでも勉強するべきにはやや賛成である。

ややの理由

勉強しない人には、理由がある。

  • 育児が大変
  • 家事が大変
  • 趣味を優先したい

それを否定するわけではない。育児や家事をしながら仕事をするだけでも大変で、

それをしている人には頭が下がる。

独身でも、趣味に没頭してリフレッシュしているリア充の人は羨ましいが、

それはそれでいいと思う。

それでも、エンジニアという職業を選んだ時点で勉強し続けることは義務だと思う。

勉強しないならば、その人はエンジニアに向いていない。

自分が勉強が好きで実際人よりも勉強していると思うので、

自分を優位に立たせて正当化したいという裏の目標もあるのかもしれない。

どうして義務なのかをロジックで説明できないので、やや賛成。

社会人が勉強するべき理由

ITエンジニアに限らず社会人が勉強する理由について考えてみる。

勉強カフェの存在

私は勉強カフェの会員で、勉強はもっぱら勉強カフェで行う。

勉強カフェとは、社会人のための有料自習室だ。

勉強カフェにはいろんな目標を持った人が集まって勉強している。

  • 資格の習得のための勉強
  • 自己啓発の勉強
  • 転職のための準備
  • 大学受験や院試受験

勉強カフェはとても混んでいて、土日はいつも満席。大繁盛している。

勉強カフェにいると、みんな社会人になっても頑張って勉強しているので、

自分も勉強を頑張ろうという気持ちになる。

なぜ社会人になっても勉強するのだろうか?

なぜ、社会人になっても勉強するのだろうか?

私の個人的な意見では、自分がもっともっと成長したいからであり、

成長することはかっこいいからだ。

仕事で成長の機会を与えられる人はラッキーだ。どんどん成長していけばよい。

しかし、自分の場合は、仕事で成長の機会を与えられたと感じたことはあまりない。

仕事をしていても、自分の成長につながらないので、

プライベートで勉強をして、成長の喜びを味わっているというわけ。

一般的なこととしては、世の中の流行や技術は絶えず進歩していて、

それに遅れをとらないためにも、勉強をしないといけない。

これは、ITエンジニアに限ったことではなく、どの業種についても言えることだ。

ITエンジニアが勉強するべき理由

技術の進歩についていく

しかし、ITエンジニアは、他の業種に比べてことさら技術の移り変わりが激しい。

なので、技術の進歩についていくためにも、勉強しないといけない。

技術は陳腐化する。流行のプログラミング言語も、10年経てばガラリと変わる。

だから、新しい言語を学んだり、新しいフレームワークを試したりする。

35歳定年説というのは、新人研修の時にならった知識で食いつないできて、

それ以上の勉強をしてこなかった人が、行き詰まることを指しているのではないか?

Hackingにワクワクする

新しい技術というのは、既存の技術の改良である。

なので、既存の技術がHackされて、効率や性能が改善されているのだ。

そこに、ワクワクする魅力を感じる。

できないことができるようになる、これには魅力を感じるだろう。

これに賛同できない人は、エンジニアに向いていない。

なんの勉強をするべきなのか

業務に応用できるかもしれない勉強をする

今の業務に役立つかもしれない勉強をする。

できれば、業務に応用することを考える。

これが自分にとっては、最もモチベーションが上がる勉強の内容。

その裏には周囲に努力が認められたいという欲求があるし、

努力が報われたいという欲求もある。

勉強したけれども、業務に応用するには転職するしかないものは、

勉強しているときは楽しいけれども、それが終わると一体なにをやっていたのかと、

後悔することが多い。

私は、MOOCを 30以上受けてコンピュータ・サイエンスの基礎から応用までをざっと

勉強したけれども、役に立ったのはほんの少し。虚しくなってしまう。

転職に役立つ勉強をする

スキルチェンジとして、転職に役立つ勉強をしてみるのもあり。

私は、機械学習の勉強を今している。ゆくゆくは、データサイエンスに絡んだ仕事を

したいと考えている。今からでは遅いのではないか?そういう不安もあるが、

決めたことなので、挫折するまで突き進む。

資格の勉強はグレーゾーン

資格は役に立つと判断したら、取得すればいい。

会社から強制されて取る資格が最もよくない。

それらは嫌なものであり、身につかないからだ。

資格は、持っていると、技術の証明になる。

日本でもっとMOOCが流行ればいいのだけれども、

5年以上立ってもMOOCは転職では生きない。結局IPAの資格が強い。

自分の職場について

勉強しないと新しい技術を取り入れることができない

昔話であるが、自分の職場は、組込み系ソフトの職場なので、C言語が重要視されていた。

そんな職場でC++の導入をしたら、オブジェクト指向を理解していないのにC++を使うものだから、

結局、C++で書かれた手続き型のコードが量産されたという話を聞いた。

今は、随分改善された。新人教育でUMLの書き方を教わりUMTPの資格取得が推奨されたりして、

現場もオブジェクト指向が浸透している。

ただし、これからは、関数型言語の時代である。オブジェクト指向になれた人たちが、

関数型のパラダイムに接した時、結局関数型言語であるにもかかわらず手続き型の書き方

をしてしまうのではないかと思う。

また、自分が配属されたとき、部署の多くの人はmuleをつかって開発をしていた。

muleってなに?という人が多いと思う。Emacsよりも低機能なエディタだ。

今はIDEがとても進化しているにもかかわらず、muleを愛用している人がたくさんいた。

テストを書くという習慣もなかった。現場はprintデバッグでテストを行っていて、

gdbを使う人すら少数だった。

アンテナを張って時代の流行についていかないと、こういう現場になる。

なぜうちの職場の人は勉強しないのだろうか

ここからは、批判になるかもしれないので、読み飛ばしてください。

うちの職場の人は勉強しない。新しい技術に目を輝かせない。

これを書くととても部署を批判していることになって、

職場の人に見られると恥ずかしいのだけれども、本質だと思うのであえて書くと、

学歴の偏差値が低い集団だからだと思う。

よくわからない理系の大卒が新入社員として入ってくる。高専生も多い。

早慶上理、MARCH以下の大学から入ってくる。

偏差値が低い大学卒ということは、勉強をあまり昔から熱心にするという習慣がないのだと思う。

能力も低く、向上心も低く、平和で平凡な生活を大切にする人たちが集まっている。

英語ができなかったら、TOEICの勉強をするはずなのだけれども、TOEICの平均点も低い。

もちろん社会人になって、勉強の必要性を感じて伸びていく人もいる。

それは少数だ。総体として、意識低い系集団の集まりなのだ。

さらに、うちの部署は、親会社の下請け企業で、

親会社に頭を下げてマンパワーでなんとか開発して納品する文化がある。

残業も多いので、余計に勉強をしようという気持ちは起こらない。

そして、稼いだお金は趣味に費やすのだ、みんな趣味やプライベートは充実している。

技術力がないのに、マネージャーになっている人もたくさんいる。

私は、そういうマネージャーをあまり尊敬していない。

もちろん技術力と管理能力はわけて考えるものだけれども、

技術力がベースにないマネージャーはなんかヤダ。

どうやって部内の文化を変えようとしたか

自分は、この文化が嫌いなので、なんとかしようとした。

研修があり、(この研修をまじめに遂行する人はいないのだけれども)、

その課題として、部内の文化を変えようとした。

まず実施したことは、アンケート調査。職

場の部員全員に直接ヒヤリングを実施して全員分の意見を集めた。

将来自分の仕事がなくなることに危機感を持ってはいるものの、

なにを勉強すればいいかわからないという人が多くを占めた。

仕事に対する危機感はみんな持っていて、部内に蔓延していた。

10年20年同じ方法で開発してきたけれども、この先やっていけるのかという危機感はある。

しかし、なにを勉強すればいいのかがわからない。

仕方がないので、会社が推奨しているLPICの勉強を頑張る人が多い。

LPICの勉強をしたところで、将来の仕事が安定するのか?

そこで次に実施したことは、

新しい技術を知ってもらうためのメルマガを週一で発行することにした。

世の中で起こっている技術革新や、開発環境、プログラミング言語について、

毎週記事を書いて、部内に配信していった。

重いテーマについては、勉強会を開いたりもした。部内集会で発表した。

また、マネージャーや部内の技術顧問にインタビューをして、

彼らが部内に対して思っていることをヒヤリングして、部内に発信した。

気になる結果は・・・

そういう活動を通じて、部内はどう変わっていったか・・・!?

ここからが面白いところなのだけれども、自分自身がここでうつ病にかかって休職した。

2年間休職したけれども、もうあと2週間で復職予定だ。

果たして部内の文化はどうなっているのだろうか?

第二幕へ続く!!

23 Aug 2017, 09:32

プログラミングのための線形代数と確率統計がわかりやすい

とてもよい数学の本を読んでいるので、いまさらながら紹介。

  • プログラミングのための線形代数
  • プログラミングのための確率統計

モチベーション

機械学習のための数学の復習をしている。

この本を読む前に、マセマシリーズの線形代数・微分積分・統計学を読んだ。

マセマシリーズは、大学の試験対策本のようで、

テストを突破するのに効果を発揮しそうな書き方だった。

随所に注釈があり、ページを遡って読み返す必要がない。とても良い本。

でも、マセマはガチ。定理とその証明に対して手を抜かない。

そのため、定理、証明、定理、証明という、数学書にありがちなサイクルを繰り返す。

そのため、その数式や定理がどういう場面で役に立つのか、

その意味がよくわからないまま読み終わり、理解した気になってしまった。

そこで、数式の意味をイメージで捉えることに注力している本シリーズ、

「プログラミングのための〜」シリーズに手を出した。

バックグラウンド

一応情報系の学部を大学で専攻してた。

線形代数の本、実は自分が学生のころに購入して読破した。

けど、今となってはすっかり忘れてしまったので、再読。

大学の専攻が情報理論だったこともあり、確率はちょっと自信があるが、統計は全くダメ。

特徴

明確なスローガンがある

この本たちには、スローガンがある。

  • 線形代数: 行列は写像だ
  • 確率統計: 確率は面積だ

この考えを全面に押し出して、議論が進んでいく。

視点が与えられて、それにそって議論が進んでいくので、全体の見通しがとても良くなる。

また、著者らは、厳密な理屈よりも、意味を伝えることを重視している。

豊富な図が多用され、イメージによって数学を理解することができる。

コラムが読者視点

コラムが読者の視点でかかれている。たとえば、

  • 「これってホントに成り立つの?」
  • 「ちゃんと証明、説明してよ」
  • 「これは難しいよ」

という感じで、口語調で書かれている。

そういう質問をしたかったというかゆいところに手が届くのだ。

そして、コラムがものすごく丁寧に、ふんだんに書かれているのも特徴。

意味やイメージ、応用を重視

定理と証明を繰り返す、従来の数学書とは一線を画する。

まず大事にしているのが、その定理や数式がなにを意味しているかということだ。

それが、豊富なイメージと丁寧な説明で詳細に書いてある。

また、こういう場面に役に立つという応用も書かれていたりする。

プログラミングのための・・・あまり関係ない

プログラミングのためのと名を売っているものの、

プログラミングのコードがバリバリでてくるわけではない。

線形代数だったら、写像のアニメーションを表示したり、

確率だったら、シミュレーションをしたりした結果がちょこっと載っているのみ。

※プログラミングを求めるのなら行列プログラマーとか。

そうではなく、意味を理解して、コンピュータで行列や確率を扱うときの、

理解を深めようというのが趣旨。

速習コースが用意されている

線形代数

本論の説明と、コンピュータで数値計算をする章や、

手で計算する章は、印がついて分かれている。

コンピュータによる数値計算は学生のころはそういう授業があったので、よく参照したけれども、

意味を知り理解を深めることが目的な今となっては不要。

手計算も、試験を受けるわけではないので、不要。

なので、数値計算と手計算を省略して、本筋のみをなぞる、速習コースで勉強した。

確率統計

第一部と第二部に分かれている。

第一部で、確率論の基礎をみっちりやって、第二部で応用的な話題を扱う。

自分は第一部を読んで、機械学習に関連しそうな推定論と情報理論をつまみ読みしている。

おわりに

この本は数学書の中でも異色の部類にはいるが、とてもわかり易い。

マセマで王道をなぞったあと、モヤモヤしていた部分の霧が晴れるようで、

これは、という感動が随所にあった。

また、線形代数は学生時代に読んだものの、まさか10年の時を経て、

再び読むことになるとは思っても見なかった。

そして、10年経った今でも内容が色あせず、

むしろ機械学習ブームで社会人のやり直し数学の本として、

注目を集めいてることは素晴らしいと思う。

惜しむらくは、プログラミングのための微分積分シリーズがないことかな。

22 Aug 2017, 11:38

LPICの勉強のやる気がおきない

はじめに

LPIC L2 の勉強をしているのだけれども、どうもやる気が起きない。

なぜやる気が起きないのか分解してみた。

モチベーションが上がらない理由

会社からの強制で資格を取らされる

自分は取りたいと思っていないのに、会社から強制的に資格取得を目標にされて、

受験させられる。これがまずモチベーションが上がらない最もな理由だ。

自発的にではなく、強制的に受験の勉強をしなければいけない。

5年で資格が失効する

LIPCの資格は5年経ったら失効してしまう。

LPICの資格を保持し続けるには、5年ごとに高い受験料を払って受験しないといけない。

そういうビジネスモデルが腹立たしい。

ググればわかる

自分はLinuxが好きで、もちろん普段からUbuntuを使っている。

過去には、CentOS, Linux Mint, Arch Linuxを使って、今はUbuntuに落ち着いている。

ArchLinuxを使っていた時は、ArchWikiという素晴らしい情報源があった。

わからないことは、ほとんどそこを見れば解決方法が見つかった。

またそうでなくても、必要になったらググッてコマンドを見つけてインストールして使った。

障害でハマった時は、昼夜潰して情報をあさって解決した。

クリーンインストールもなんどもした。

そうやって、苦労してググった知識のみが結局身につくのではないかと思う。

紙面上で暗記した知識はすぐ忘れる。

LPICで問われる嫌な問題の一つは、オプションの種類についてだ。

わからなければ、zshやfishならばタブを押すだけで説明がでるし、

そうでなくてもhelpでしらべればわかることだ。

それを暗記しなければいけない。これが嫌だ。

すぐ忘れる

L2ともなると、サーバ管理系のコマンドがたくさんでてくるけれども、

サーバ管理者でもないので、使わないコマンドがほとんど。

いつになったら役に立つのかわからない。

サーバ開発やサーバ管理をしているわけでもないので、覚えた知識は使わない。

使わないと、忘れてしまう。歴史や地理の暗記と同じ。

テスト前に丸暗記した知識は忘れてしまう。

おわりに

批判ばかりなので、最後は肯定的に締めよう。

自分は井の中の蛙で、LPICの意義が見えていないだけかもしれない。

実は、将来長い目でみれば役に立つのかもしれない。

将来の自分がこの文章を読んで、過去の自分をビンタするかもしれない。

しっかりするんだ!!

資格を持っているから、Linux開発の仕事にアサインされたり、

部内のサーバ管理者に任命されたり、

自宅サーバを立てるときにやくにたてばいいなと思う。