Hello, Stupid World!

Hello, Stupid World!

いろいろとメモ代わりに書いていきます。

Amebaでブログを始めよう!

Eclipseを日本語化する為にPleiadesを入れます。


1.Pleiadesダウンロード

Pleiadesは公式サイトからダウンロードしますが
Linux版は下図のように「Pleiadesプラグインダウンロード」と
書いてある所からダウンロードします。

誤ってAll in Oneをダウンロードしないように注意して下さい。



2.Pleiades展開

ダウンロードしたらunzipコマンドやマウスを使って展開します。
今回はマウス右メニューから展開しました。


3.必要ファイルをコピー

2で展開した中にあるfeaturesとpluginsをEclipseを
インストールしたフォルダ配下にコピーします。
cp -r コマンドを使ってコピーしました。


4.Pleiades有効化

Eclipaseの設定ファイルを変更してPleiadesを有効化します。
eclipseディレクトリ配下のeclipse.iniに以下を追加します。

-Xverify:none
-javaagent:plugins/jp.sourceforge.mergedoc.pleiades/pleiades.jar

分からなくなった場合はeclipse配下のreadmeを参照して下さい。



ここではgeditを使って編集しています。


5.日本語化確認

ここまでできたら、無事に日本語化されているか確認します。
eclipseを起動します。


日本語化できました。
うまくいかない場合は-cleanオプションをつけて起動してみて下さい。


以前、openjdkの1.8をインストールしましたが
実は、その時に困った事が起きました。

それは既にopenjdkの1.6が存在していて
1.8をインストールした後も1.6が実行されるように
なっていた事です。

こんな場合に1.6は消さずに簡単に切替える方法が
Linuxにはあります。

alternativesコマンドです。



有名どころは最初からalternativesの対象となっていますし
なっていない場合でもalternatives --install により対象にできます。

alternatives --display
により、現在有効なバージョン、切替わる内容、優先バージョン等が
分かります。

有効なバージョンを切替える場合は
alternatives --config
を実行し、有効にしたいものを選択するだけです。



Eclipseをインストールします。

1.Eclipse ダウンロード

まずはEclipaseのダウンロード。
下記のURLからWeb系の開発に良いJ2EEをダウンロードします。

https://eclipse.org/downloads/

ダウンロードしたファイルはtar形式でアーカイブされているので
展開します。


2.ダウンロードファイルの展開

アーカイブファイルの展開はtarコマンドです。

tar -xvzf ファイル名
今回はeclipse-jee-mars-1-linux-gtk-x86_64.tar.gzというファイルでした。
展開したディレクトリは/opt に移動。


3.実行

無事にeclipseの準備ができたか実行してみます。
ディレクトリ配下にあるeclipseファイルをダブルクリックか
メニューから開くを選べば実行されます。


追記

インストール時、間違えて64bit版をダウンロードしてしまいました。
自分のLinuxが32bitか64bitか確認したい場合には

uname -a

と入力して i686 i686 i386 と表示されれば32bit
X86_64やamd64と表示された場合は64bitです。
JDKのバージョンも確認できたので新しいバージョンを入れます。

yumを使ってバージョンアップするのですが、yumで可能か
調べます。

1.yumでインストールされるものを調べる

これはyumコマンドのsearchオプションで可能です。
今回はopenjdkを対象とするので

yum search openjdk
となります。

実行結果


調べてみると1.8がインストールできるようです。
ではこれをインストールしましょう。


2.openjdkのバージョンアップ

上記で見つけたjava1.8のopenjdkをインストールします。
インストールにはroot権限が必要なので
一旦suしてrootになります。

rootになったらyumを使いインストールします。

openjdkと書かれているもの以外にopenjdk-develという
ものがあります。

openjdkはOracleのJavaでいうランタイム環境(JRE相当)
openjdk-develは開発環境(JDK相当)なので
今回はopenjdk-develを入れます。

コマンドは
yum install java-1.8.0-openjdk-devel
です。

インストール中は依然情報や進捗状況が表示されます。


途中で本当に入れるか聞かれるので y を入力します。
Complete!と表示されたら完了です。

補足

間違えたものをインストールしてしまった場合は
yum remove コマンドを使って削除ができます。
ただし、依存ソフトも一緒に消えるので注意して下さい。
Java環境を作っていきたいのですが、Linuxでは最初から
Javaが入っている事が多いので、まずはその確認をします。

1.Javaのバージョン確認

端末からjavaコマンドにversionオプションをつける事で
バージョンが表示されます。

構文:java -version

実行結果です。
入っているバージョンが1.6.0_17と表示されています。
どうやら古いので新しいのを入れていきましょう。

ちなみに、OpenJDKと表示されていますが
これはJavaのオープンソース版です。

開発にはOracleだけでなく、アップルやIBM、SAP等も
参加しています。

OracleJDKとは基本的に互換性があります。


2.共通的な確認方法(yum)

yumを使ってインストールした場合は
yum list installed コマンドでインストール済みのソフトを
確認できます。

構文:yum list installed

今回はJDKを探す為に
yum list installed | grep jdk
としました。



3.共通的な確認方法(rpm)

rpmパッケージの確認はこちらを使います。

構文:rpm -qa

今回は
rpm -qa | grep jdk
としました。



Javaのようにコマンドでバージョンを確認できる場合は
それでも良いし、できない場合や方法を忘れた場合は
yum list installed や rpm -qa を使うと良いです。
かなり空いてしまいましたが、また暇が出来たら書いていきます。
今回からはCentOSでJava実行環境を作っていきます。

1.ユーザ作成

まずは開発用ユーザを作成します。

ユーザの作成はuseraddコマンドを使用します。
引数はユーザ名です。

構文:useradd ユーザ名

今回は「dev」という名前の為、「useradd dev」と入力しました。


2.パスワードの設定

パスワードの設定はpasswdコマンドです。
引数はパスワードを設定する対象のユーザ名を指定します。

構文:passwd ユーザ名

入力するとパスワードを2回聞かれる(2回目は確認用)ので
入力します。



実行結果ですが、このようにパスワードが簡単過ぎると
怒られてしまいます。

3.ユーザの確認

正しくユーザが追加されたか確認したい場合は
/etc/passwdファイルを見ることで確認できます。



上記のように、ユーザの一覧が表示されます。
内容は詳しく説明しませんが、ホームディレクトリや起動シェルが
設定されています。

今回でMockitoは終わりです。

Mockitoでモックの検証を行っている時に何回、モックが呼ばれたのか
知りたい状況があります。
そんな時に便利なメソッドを紹介します。

たくさんあって大変ですが、一気に。

 //モックの作成
 LinkedList mockedList = mock(LinkedList.class);

 //モック使用
 mockedList.add("once");
 mockedList.add("twice");
 mockedList.add("twice");

 //mockList.add("once")が一度呼ばれているか検証。
 //一度も呼ばれていなかったり、二回以上だと例外が発生
 verify(mockedList,
times(1)).add("once");

 //上のtimes(1)と同じ意味
 verify(mockedList).add("once");

 //二回呼ばれているか
 verify(mockedList,
times(2)).add("twice");

 //一度も呼ばれていないか。times(0)のエイリアス
 verify(mockedList,
never()).add("never happened");

 //一回以上呼ばれているか
 verify(mockedList,
atLeast(1)).add("twice");

 //上のatLeast(1)のエイリアス
 verify(mockedList,
atLeastOnce()).add("twice");

 //呼ばれたのは二回以下か
 verify(mockedList,
atMost(2)).add("twice");

具体的に呼ばれる回数が分かっている場合にはtimesを使います。
何回以上と指定する場合にはatLeast、何回以下ならばatMostです。

これでテスト対象のコード中で指定したメソッドが何回呼ばれたか
検証できます。


Mockで動作をすげ変える方法を今まで紹介してました。
ここでは、一部の動作をすげ替えて他は普通にメソッドを実行させる
方法を紹介します。
そのような機能をスパイ(spy)といいます。

以下のように使います。

 List list = new LinkedList();

 //スパイの作成
 List spy =
spy(list);

 //スパイの動作を設定。sizeメソッドを呼んだら100になるようにする。
 when(spy.size()).thenReturn(100);

 //スパイは動作設定してないメソッドは元のが動く
 spy.add("one");
 spy.add("two");
 System.out.println(spy.get(0));

 //100が戻る
 System.out.println(spy.size());

 //こちらも設定してないので元のが動く
 verify(spy).add("one");
 verify(spy).add("two");


全3回紹介しました。
他にも機能はありますが、自分がよく使うのはこのくらいです。
前回に引き続き、Mockitoをやっていきます。
基本的なモックの使い方や検証(verify)は前回、紹介したので
今回はもう少し発展系を。

モックの動作を設定する際や検証する際にメソッドの引数が
ランダムだったり外部要因で変わり特定できない場合があると
思います。

そのような場合に型だけを指定できるany~というメソッドがあります。

見た方が早いので具体例を

 //モックの作成
 LinkedList mockedList = mock(LinkedList.class);

 //モックの動作を設定。anyIntでintなら何でもという扱いになる。
 when(mockedList.get(
anyInt())).thenReturn("element");

 //実行(elementと出力される)
 System.out.println(mockedList.get(999));

 //検証でもany~が使える
 verify(mockedList).get(
anyInt());

上記、コメントの通りですがany~()とする事で具体値が
分からなかったり、決められない場合でもモックが使えるので
非常に便利です。
当然、anyIntだけでなくanyStringやanyBoolean、anyListなどもあります。


モックの設定時、上記ではwhen().thenReturn()の形で書きます。
例外を発生させる場合にはwhen().thenThrow()

voidで戻り値が無い場合は以下のように書きます。

 //モックの作成
 LinkedList mockedList = mock(LinkedList.class);

 //モックの動作を設定(戻り値が無い場合)。ここでは例外を発生させる
 
doThrow(new RuntimeException()).when(mockedList).clear();

 //例外発生
 mockedList.clear();

上記のようにdoThrow().when()という形です。

Mockitoを使う事でモックの作成が簡単にできるようになります。
次回もMockitoの記事の予定です。
忙しくブログ書いている暇が無かった為、大分空いてしまいました。

GWを利用して投稿してみます。
今回はMockitoを備忘録代わりに書きます。

まずMockitoですが、モックライブラリと呼ばれるもので
テストの為に一部の動作をすげ変えたり、期待通りの動きをしたか
検証したりするものです。

具体例を出すと

昼に呼ぶと「こんにちは」、夜に呼ぶと「こんばんは」と出力する
メソッドがあるとします。
このメソッドをテストしたい場合、動かす時間によって結果が変わって
しまい、昼にテストしても「こんばんわ」が出るか確認できません。

このような場合に時間を取得する処理だけをモック化する事で
「こんにちは」と出させたり、「こんばんは」と出させたりできます。

一言で言うと、自身が自由にできない外部の要因がある場合に
モックライブラリを使うと自由にできると言った感じです。

ライブラリは以下からダウンロードします。
Maven等を使っても良いです。

http://mockito.org/

実際にソースを見ていきましょう。

[期待通りの動きか検証]
 //①staticインポートすると使いやすい
 import static org.mockito.Mockito.*;
 public class Test1 {
@Test
public void test() {
//②モック作成
List<String> mockedList = mock(List.class);

//③テスト
mockedList.add("one");

//④呼ばれたか検証。呼ばれてない場合、例外発生
verify(mockedList).add("one");
}
 }

基本は途中のコメントの通りです。
モック作成して、テストコード実行して検証します。
検証はverifyで行いますが、上記の場合はaddメソッドを引数"one"で
呼び出しているかという検証になります。

もし、呼んでいなかった場合は例外が発生します。



見ての通り、どの箇所のverifyが失敗しているのか
実際にはどんな値が来たのか分かるようになっていて便利です。

次に動作をすげ変えてみます。

[動作のすげ変え]

 //①モック作成
 LinkedList mockedList = mock(LinkedList.class);

 //②させたい動作を記述
 when(mockedList.get(0)).thenReturn("first");
 when(mockedList.get(1)).thenThrow(new RuntimeException());

 //③テスト。firstが帰ってくる
 System.out.println(mockedList.get(0));

 //④テスト。RuntimeExceptionが発生する
 System.out.println(mockedList.get(1));


上記のようにwhenメソッドで指定したメソッド(+引数)が呼ばれた場合に
thenRturnの中身が帰ってくるようになります。
例外を発生させたい場合はthenThrowです。
また、モックというのは元のクラスにあるメソッド全ての動作が一旦クリア
されるので、この後にmockedList.get(100)とかやってもnullが帰ってくるだけです。

注意点ですが、上記のwhen + thenReturnは戻り値がvoid以外の
メソッドに対してのみ使えます。

あと、verifyはあくまで動作したか検証するだけなので上記で
verify(mockedList).get(1);とか書いてもRuntimeExceptionは発生しません。

voidの場合は他のやり方で行いますが、次回以降に説明します。
最近、見積りをする事があったのでまとめておきます。

自分は見積りの際に、よくファンクションポイント法を使います。

KKD(経験や勘)だと見積もる度に値が変わるし
COCOMO(コーディング行数から求める)だと、かなり設計が
終わっていないと見積もれない。
(COCOMOⅡは違うらしいけど)

ファンクションポイントは複数のやり方がありますが
その中でも試算法や概算法は工程が早い段階から使えるので重宝します。

ファンクションポイントの良いとこが、ブランド力とでも言うか、有名な事です。
どうしてこんなかかるんだと聞かれた時に一般的に使われてる
ファンクションポイント法で計算した結果ですと言えば、納得してもらえる
事が多いので、便利です!

ファンクションポイント法は大きく3つの方法があります。
■ IFPUG
一番、精度が高い方法。機能やファイル数から規模を算出します。
機能等が決まらないとできないので外部設計完了後に使う。

■ 概算法
IFPUGと同じく機能、ファイル数から算出するが
複雑度はデフォルトで計算する。
その為、機能の詳細までは決まっていなくても使える方法。

■ 試算法
ファイル数だけから規模を算出する。
機能が決まっていなくても使える方法だが精度は低い。

それぞれ、メリット、デメリットがあるので考慮して使います。
ただ、自分の場合は途中から再見積りなんてさせてもらえなかったり
するので大抵の場合は、概算法か試算法です。

まず、FP(ファンクションポイント)という規模を求めます。

概算法

■FP計算式
システム内ファイル数(ILF) × 7ポイント
+ システム外ファイル数(EIF) × 5ポイント
+ 入力処理数(EI) × 4ポイント
+ 出力処理数(EO) × 5ポイント
+ 検索処理数(EQ) × 4ポイント

システム外ファイルとは他システムから受け取ったファイルや
ログファイルなんかです。

FPを人月換算する際は15~20FPを1人月としています。
自社内で使うものなら35FP/人月

■例
組織マスタの登録、変更と社員マスタの登録、変更、削除、検索
処理を作る。

システム内ファイル数 2つ × 7ポイント
+ 入力処理(登録処理) 2 × 4ポイント
+ 出力処理(変更、削除) 3 × 5ポイント
+ 検索処理 1 × 4ポイント
= 51 FP

人月にすると2.5人月という所でしょうか。

試算法

■FP計算式
35ポイント × システム内ファイル数 + 15ポイント × システム外ファイル数

システム外ファイルは細かい編集処理等がないので少ないらしいです。

■例
前述の例で試算すると

システム内ファイル数 2 × 35ポイント
= 70FP
≒ 3.5人月ぐらい