[OCJP]コンストラクタによるstatic変数、final変数の初期化

package june20150623;

public class ConstractaDoubleInitializeValue {

	public static void main(String[] args) {
		new Parent();
	}
}

class Human {
	final int age;
	final static int heigt; //	コンパイルエラー！final static 変数は、変数定義時、staticイニシャライザにて初期化が可能。
	final static int weight;//	final static 変数は、変数定義時、staticイニシャライザにて初期化が可能。
	static {
		weight = 50;
	}

	public Human(int age) {
		this.age = age; //	final変数への初期化はコンストラクタでは可能。
	}
}

class Parent extends Human {
	public Parent() {
		this(10);
		age = 20; // コンパイルエラー！final変数への初期化は一度のみ許される。
	}

	public Parent(int age) {
		super(age);
	}
}

class Child extends Human {

	public Child(int age) {
		super(age);
	}
}

実行結果

Exception in thread "main" java.lang.Error: Unresolved compilation problems: 

ブランクの final フィールド heigt は初期化されていない可能性があります

final フィールド Human.age には代入できません

at june20150623.Parent.<init>(ConstractaDoubleInitializeValue.java:12)

at june20150623.ConstractaDoubleInitializeValue.main(ConstractaDoubleInitializeValue.java:6)

[OCJP]instanceof演算子について

・instanceofには2つの記法がある
　①（ クラスオブジェクト instanceof クラス）
　②（インタフェースオブジェクト instanceof クラス）　

　①においては、クラスオブジェクトがどんな型であっても演算可能だが、
　②においては、インタフェースオブジェクトと比較対象のクラスに継承関係か実装関係が無いと、コンパイルエラーになる。
　
　そもそもの目的がサブクラス、クラスであるか、実装クラス、実装クラスのサブクラスであるかを問うためのものである。すなわち、継承関係や実装関係を問えるようなオブジェクトを左辺に指定しなくてはならないのは当然であり、それはコンパイラが検証出来る範囲でもある。

[調べ物]よくITサイトで話題になっている色々なものの調べ。

管理者はSIerのために、枯れたフロント開発技術を利用しています。

昨今の技術、用語について軽く調べました。

・リアクティブプログラミング

     物事にリアルタイムで反応するコードのこと？  

・Grunt

     JavaScriptベースのタスクランナー（ビルドツール）

・Gulp

     Node.jsのStreamAPIを利用したビルドツール

     Gruntが抱えるいくつかの問題を解決した。

・MVW（Model-View-Whateverパターン）

     「MV*について議論するのは時間の無駄だから、そんな暇があったらコードを書け。MV*の*の部分なんて"Whatever"でいいんだ。」という主張のようです。

     http://qiita.com/zoetro/items/a45dbc18bb2b22e944b2

・Pivotal Tracker

     http://www.atmarkit.co.jp/ait/articles/1205/14/news150.html

• アジャイル開発マネジメントをWebサービス化
• 入力項目が少なく、シンプルなワークフロー
• Webブラウザで操作するが、ドラッグ＆ドロップで操作できる高い操作性
• Webサービスで提供しているので、インストール不要
• HTTPS接続可能
• 日本語入力可能（ただし、メニューは英語のみ）
• 外部APIから操作可能
• 公共機関、非営利団体、個人利用、教育機関の場合無償で利用可能

     Webサービスベースのため、日本の企業システム開発では絶対に許されない。

・Yeomen

     WEBアプリケーションビルド・テストツール

     http://www.atmarkit.co.jp/ait/articles/1407/02/news040.html

     今風のWebアプリのための土台／基盤を作ってくれるツール

     Grunt、Bower、Yoから成る。Gruntは、JavaScriptベースのタスクランナー

・Slack

     チャットアプリ

・マルチレゾリューション

     異なる解像度への対応。各スマフォに対応？

・Google Page Speed

     Googleが提供するページ表示高速化のアナライザー

・YSlow

     FireFoxアドオン。パフォーマンス計測ツール。

・salesForce

     CRM（こきゃくかんけいかんり）ソフトの超大手

     日本には多くの代理店がいる。しかも代理店業は日本の技術メーカー大手だったり・・・

     

・FXML

     JavaのGUIをXMLで管理する方式。

・Node.js（同類のRhino

     サーバサイドJavaScript

     サーバサイド処理をJavaScriptの記述法で実装可能にする。

     クライアントサイド、サーバサイドの統一言語とし、開発効率を向上させる。

     なお、サーバサイドJavaScriptは、CommonsJSという標準仕様に則っている。

     http://www.atmarkit.co.jp/ait/articles/1102/28/news105.html

     Apacheは、スレッドベースであり、リクエスト数＝スレッド数であり、

     大量アクセス→スレッド大量生成→メモリ枯渇

     という障害が発生する。

     Node.jsは、イベントループであり、シングルスレッドで動作する。

     複数クライアントからのリクエストには、ノンブロッキングI/Oで対応する。

     なお、イベントループC10K問題にて話題になった

     http://www.atmarkit.co.jp/news/analysis/200701/09/c10k.html

          簡単にいえば、OS上で扱えるプロセス番号の限界に扱えるスレッド数が制限されるという問題。

     メリット・デメリット

     http://blogs.zealot.co.jp/archives/30

     http://anopara.matrix.jp/2014/02/21/node-js%E3%82%92%E3%81%B2%E3%81%A8%E9%80%9A%E3%82%8A%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%A6/

          簡単で大量の送受信を伴う処理に非常に向いている。

          スケーラビリティは低い。

          複雑な処理の実装には向いていない。

          以下に集約されている。

          じゃあ具体的にどんな時、node.jsだと嬉しいかというと、「RESTful な API」「Twitter のキュー」「テレビ・ゲームの統計データ」のようなアプリケーションを挙げています。つまり、単純明快な処理だけど、要求の数が膨大になってしまうような事例です。

          

・ノンブロッキングI/O

     データの送受信を待たずに次の処理を行う。

     ただし、それぞれの処理ではコールバック関数を設定し、イベント駆動でコールバックを実行する。

■感想
　WEB系は企業システムとは異なる問題を抱えている。だから企業システムとは異なる進化を進む。
　人の変容が根幹にあるのだから、変化のスピードも速い。

　企業システムは、大きな工場と同じで一度作ったら当分は使い続ける。
　信頼性、保守性、可用性、機密性を重視する。

　両者のビジネスプロセスは根本的に異なる。

[OCJP][寄り道]FileChannelを用いたファイル書き込みにおけるByteBufferの利用方法について

・FileChannelは、書き込み時にByteBufferを利用できる。
・ByteBufferは、ファクトリメソッドにより生成するが、allocate,wrapの使い方に違いがある。

・allocateの場合

package june20150623;

import java.io.File;
import java.io.IOException;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;
import java.nio.file.Path;
import java.nio.file.StandardOpenOption;

public class FileChannelByAllocated {
	public static void main(String[] args) {
		Path path = new File("test.txt").toPath();
		try (FileChannel fc = FileChannel.open(path, StandardOpenOption.CREATE, StandardOpenOption.WRITE)) {
			ByteBuffer src = ByteBuffer.allocate(10);
			byte[] bytes = { 't', 'e', 's', 't' };
			src.put(bytes); // putのバイト入力によりpositionが進む
			src.position(0); // 進んだpositionを戻す。

			fc.write(src); // write時にpositionから書き込みされる。この仕様は、Javadoc(http://docs.oracle.com/javase/jp/7/api/java/nio/channels/WritableByteChannel.html)にも記載されている。

		} catch (IOException e) {
			e.printStackTrace();
		}

		try (FileChannel fc = FileChannel.open(path, StandardOpenOption.READ)) {
			ByteBuffer dst = ByteBuffer.allocate(10);
			fc.read(dst);

			System.out.println(new String(dst.array()));
		} catch (IOException e) {
			e.printStackTrace();
		}
	}
}

→実行結果

test

・wrapの場合、

package june20150623;

import java.io.File;
import java.io.IOException;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;
import java.nio.file.Path;
import java.nio.file.StandardOpenOption;

public class FileChannelByWarpped {
	public static void main(String[] args) {
		Path path = new File("test.txt").toPath();
		try (FileChannel fc = FileChannel.open(path, StandardOpenOption.CREATE, StandardOpenOption.WRITE)) {
			byte[] bytes = { 't', 'e', 's', 't' };
			ByteBuffer src = ByteBuffer.wrap(bytes); // wrapの場合、positionは0を維持する。
			fc.write(src); // write時にpositionから書き込みされる。この仕様は、Javadoc(http://docs.oracle.com/javase/jp/7/api/java/nio/channels/WritableByteChannel.html)にも記載されている。

		} catch (IOException e) {
			e.printStackTrace();
		}

		try (FileChannel fc = FileChannel.open(path, StandardOpenOption.READ)) {
			ByteBuffer dst = ByteBuffer.allocate(10);
			fc.read(dst);

			System.out.println(new String(dst.array()));
		} catch (IOException e) {
			e.printStackTrace();
		}
	}
}

→実行結果

test

[JSTQB Foundation]シラバスについて

JSTQBシラバス
http://jstqb.jp/syllabus.html

上記サイトでPDFにて、シラバスにいろいろ記載がある。

学習の目的を
K1：記憶
K2：理解
K3：適用
K4：分析
という段階に分けている。

シラバスごとに学習時間を設けており、
・テストの基礎（155分）
・ソフトウェアライフサイクルを通じてのテスト（115分）
・静的技法（60分）
・テスト設計技法（285分）
・テストのマネジメント（170分）
・テスト支援ツール（80分）
としており、合計155+115+60+285+170+80 = 865分 = 約14時間半
となる。

学習書籍の認定制度があり、
現時点では、翔泳社のソフトウェアテスト教科書 JSTQB Foundation 第3版
が学習書籍として認定されている。

＃＃＃＃
個人的な経験で言えば、テスト技法は、会社で教えられることが無かったため、経験を持って学んてきた過程がある。

テストを体系的に理解することが、システムの品質を保証する一つの道程となる。
新人にとっても、テストとは何か、品質とは何かを理解するうえで、非常に有用な試験と言える。