呪いの先に

ブリーダー事業も面白いかもと考えている佐藤です。

前回、エビ抱卵の記事を書いてから4ヶ月以上経ってしまいました。
社内では、あまり興味を示してもらえなかったので、書き続けようか、辞めようか、悩んでいたのですが、
先日、面接時に、何か質問ありますか？って尋ねたところ、エビは無事産まれたのですか？って質問があり、
気にしてくれている人もいるんだなと、嬉しかったので、続きを書きます。
※もちろん、その子は採用です！

エビの卵って孵化するまでに1ヶ月くらい掛かるようで、
かなり時間が掛かるんですよね。。。。

足でわしゃわしゃと卵に空気を送ったりと、見ていてかわいらしいのですが、
1ヶ月は長い・・・

帰宅後に毎日水槽チェックするのですが、エビがお亡くなりになっていると、
卵持ちかどうかハラハラ、ドキドキと、心臓に悪い。

水換えも、コケ掃除も、水質に影響しそうで怖くて出来ないし、
でも、やらなければやらなかったで、水は汚くなっていくし。。。
どうしたものかと葛藤の日々を過ごしていること、1ヶ月、あれ、壁に白いゴミが増えてる。

ん、よく見ると少し動いてる？
携帯のカメラでズームしてみると、、、　おお、エビの赤ちゃん！
こんなに小さいのかとびっくりですｗ

そして、面白いのが、赤いエビから産まれてきたのに、成長すると
いろんな色に変化していく。

黒や黄色、赤、透明と、水槽の中がカラフルになってく。

呪いの連鎖も無くなって、ようやく増えるようになってきたかと思ったら、
エビの赤ちゃんと同じくらいの大きさのおたまじゃくしみたいなのがいるではないか。。。
それも2匹。なんとアフリカンランプアイ（めだかの一種）の赤ちゃんではないですか。

こっちは全然気が付かなかった。

エビだけでなく、アフリカンランプアイまで！！

これは隔離して成長を見守るべきなのか！

いや、エビの赤ちゃんも多いし、水草もいっぱいだし、そのまま行こう！
きっと大丈夫！！

としたのが失敗。。。

気が付くと居なくなってました。。。

誰かに食べられたに違いない。

やっぱり隔離するべきだったと後悔しました。

なので、次産まれた時のためにと、隔離網を購入して待機。
そしたら、すぐに赤ちゃんが登場！

しかし、隔離して匿うこと2週間。中々大きくならない。。。
エビは目に見えて大きくなるのに。。。

何故、お前は成長が遅いんだ！

もっと食えー！

やきもきすること更に2週間、少し大きくなってきたので、網を撤去することに。
と、いうよりも、隔離網が汚れてきて、そこにエビやオトシンが群がり
隔離網にオトシンクルスが挟まってお亡くなりになる事故が。。。

何かが生まれると、何かが亡くなっていく。。。
これも自然の摂理なのか、それとも管理能力の無さなのか、、、
はい、完全に後者ですよね（＞＜）

水質も落ち着いて、最近は、生まれるのと、亡くなるのが
交互に起きる感じだったのですが、、、、

続きは次回、「未開の地開拓　先遣隊の運命や如何に」で、記載しますね。

説得力のある表現を身につけよう！ - さくっと紹介『ビジネスフレームワーク』

皆様。こんにちは、こんばんは。

さて、ブログで何を書こうかと思いまして。
今、製造工程に携われることに感謝しつつ、自身の今までのドキュメント作成経験が活かせる分野を書こうと思います。

今回は割とすぐに使える『ビジネスフレームワーク』を３つご紹介します。
厳密にはフレームワークじゃなくね？というツッコミを恐れず書きます。

なんか考慮漏れしてない？⇨『MECE』

MECEとは、英語で、「Mutually Exclusive and Collective Exhaustive」。。。
ともかく、ミーシーと読みます。
日本語訳で、「モレなく、ダブりなく」という意味です。
ロジカルシンキングを勉強すると最初に出てきます。

あるものの構成要素を挙げた時、モレがあっても、ダブりがあっても、説得力はなくなります。
例えば、「成人男性とは、サラリーマン + 学生 + 主夫 であるから、それら３つをターゲットにすれば網羅できている。」と判断すると誤りです。
個人経営者や、退職者などのモレがあります。
反対に、「人とは、男性と女性である。」「人とは、18歳以上と18歳未満である。」などはMECEな状態です。

どこの帳票パッケージを買えばいいか選定して！⇨『直接評価法』

「今回のシステムで必要になる、帳票パッケージ。どれを買えばいいか選定して！」と言われて、「デザインが好きだから、これにしました。」と答えて承諾してもらえる人はいないと思います。そりゃあ、説得力ないです。

製品ごとの価格や納期、機能、サポート、メンテナンスのしやすさなど、いろいろな項目を案件や状況に応じて重み付けし、その得点の合計で評価する方法を「直接評価法」と言います。
項目を洗い出す時は、（早速ですが）MECEが使えます。
また、直接評価法は、開発や作業の見積を出す時にも似たような使い方をします。
（詳しくはFP法・ファンクションポイント法）

どんなスキルを伸ばそう？⇨『SWOT分析』

SWOT分析とは、自社の強み(Strength)と弱み(Weakness)、競合や外部要因からの機会(Opportunity)と脅威(Threat)を分析するフレームワークです。
頭文字を取って、SWOT（スウォット）分析と読みます。
SWOT分析 + クロスSWOT分析で自己分析のツールとしても使われます。
自身の強みと弱みを出して、将来的にどんなチャンス(良い機会)が来るか、反対にどんな悪いこと、脅威が労働市場的に迫ってくるか、を考えます。
そこから、自身が今やるべきことを導きます。

まとめ

さくっと紹介と書きましたが、今回は使う場面が多いと思われるフレームワークを挙げました。
使い方はそれぞれ調べたほうがより理解が深まると思います。
情報をリストアップしたのは良いけれど、いまいちスッキリ整理できてない。。しっくりこない。。
上長や先輩に説明しても、いまいち納得してもらえない。
そんな時には、MECEでない状態かもしれません。
ちょうど良いフレームワークがないか探してみるのもいかがでしょうか。

JJUG CCC 2018 Springに行って来ました。

5/26(土)に開催されたJJUG CCC 2018 Springを聞きにいきまして、今回はその感想を書きたいと思います。

Java10まとめと、どうなるJava11

LINEのきしださんのスピーチでした。
タイトルの通り、Java10でリリースされた内容と、Java11でリリースされる予定の内容の発表だったのですが、
そのなかで自分がおっと思ったのは、Java11で追加が検討されている、Switch Expressionsでした。
何かというと、Switchの書き方が変わりコード量が変わるのが魅力だと思いました。

今までのSwitch

int numLetters;
switch (day) {
    case MONDAY:
    case FRIDAY:
    case SUNDAY:
        numLetters = 6;
        break;
    case TUESDAY:
        numLetters = 7;
        break;
    case THURSDAY:
    case SATURDAY:
        numLetters = 8;
        break;
    case WEDNESDAY:
        numLetters = 9;
        break;
    default:
        throw new IllegalStateException("Wat: " + day);
};

検討されているSwitch

int numLetters = switch (day) {
    case MONDAY, FRIDAY, SUNDAY -> 6;
    case TUESDAY -> 7;
    case THURSDAY, SATURDAY -> 8;
    case WEDNESDAY -> 9;
};

他にも検討されていることがたくさんあって、
半年ごとにリリースするのにここまで変えるのかと。しかもめっちゃ便利！素敵！と思ったセッションでした。

Java10 and Java11 at JJUG CCC 2018 Spr from なおき きしだ

www.slideshare.net

JavaエンジニアのためのDocker入門 〜 仮想開発・テスト環境構築 〜

きの子さんのスピーチでした。
JJUG CCC 2017 Springできの子さんの「JavaエンジニアのためのScala入門」というセッションを聴講したらとっても面白かったのと、
Dockerってクジラのあれでしょぐらいの知識（？）しかないということもあり、聴講した結果。。

このブログ記事書き終わったらDocker使ってみます！
というぐらいハートにズキュンと来たセッションでした。

何が響いたかというと、開発環境を構築する場合、今まではVirtualBoxを使っていたのですが、やっぱり、OS入れるとなると結構時間かかるんですよね。
Dockerの場合、コンテナ単位でOSを入れるわけではないので、その時間が短縮できるのはとても魅力的ですし、そもそもがAnsibleやChefのように構成をファイルで管理するのがとてもいい！
ファイルさえあればコマンドひとつで環境が出来て、時間もかからないなんて素敵！というわけで、まじでいれます。

https://speakerdeck.com/sammy7th/javaenziniafalsetamefalsedockerru-men-number-jjug-ccc-number-ccc-e5speakerdeck.com

Java から TypeScript へ 切り替えて加速するサーバーレス開発

lulznekoさんのスピーチでした。
マイクロアーキテクチャを採用し、AWS Lambdaのコールドスタートの壁にぶち当たった結果、Javaで書いていた内容をJavaScriptで書いたという、斬新なお話だったのですが。。

いや、本当。JavaScriptは TypeScriptで書いたほうがいい。と本気で思いました。

私はシベスピ内では少ない動的型付き言語出身なのですが、
やっぱりね。静的型付けに比べると動的型付き言語はチェックしなければいけない内容やテストの量は増えるんですよ。
静的型付けなら引数のチェックなんてnullかどうかぐらいでいいかもしれないですが、動的型付けは本当にそれが意図した型なのかまで調べなければいけない。
そういう意味では静的型付け的にJavaScriptが書けるってことは素敵以外の何者でもない。
個人的に一番刺さったのは、非同期コールバック。JavaScriptだと本当にめんどくさいんですよね。あれ。

riotz.works

DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話

ジャストシステムの福嶋さんのスピーチでした。
内容もそうですが、話し方もとても面白い！Twitterで他の方が呟かれていたのですが、動画にしないのがもったいないスピーチでした。

DDDのお話について言えば、YAPCではてなの方のDDDのセッションを聞いたことがあるぐらいだったのですが、まずこれだけは言いたい。

本も高いし！（5000円越え）そもそも本もドキュメントも少ないし！（本で言えば2冊ぐらいで両方持ってるけどすごい量）
設計思想がいいのは分かるけど、概念が分かりにくいくせにドキュメントも少な(ry

そんな中で、どうしてDDDを採用したのかも含めて勉強になる話でした。

DDDの話だけではなく、どう開発を進めていくか（コーディング規約・レビューの観点）についても話されていて、散々決めてもヌルポでばっこんばっこんおちるんだよ！と、DDD以外の話についても勉強になるセッションでした。

DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話 from JustSystems Corporation

www.slideshare.net

余談：恥ずかしい話

スポンサーブースにヌーラボさんがいらっしゃって、私は個人的にCacooやBacklogをめちゃくちゃ使っているという前提の中、開発者の方と出会った結果。。

「もう本当大好きです！あのUIや機能が素晴らしすぎ(ry」

と愛の告白レベルでどれだけ好きかを伝えまくったという、振り返ればめちゃくちゃ恥ずかしいというか相手も照れていたというかぶっちゃけ困っていたというかなんと言うか。。

そんな告白をしつつも聞いた内容として、素敵だと思ったのが「説明書を読まなくても、エンジニアでなくても使えるインタフェースを目指しているんだ」という話で。

やっぱり人の話を聞くのは楽しいって言葉だけで表せないぐらい素敵で。秋も絶対行こうと思いました。

選択について

2度目の投稿になります。
山田です。

生きているといろんなタイミングで選択を迫られると思います。
お昼なにを食べようという小さなものから、
どんな仕事に就こうという大きなものまで。

そんな時より良い選択をできるようにするには、
どうしたら良いのかを考えてみました。

まず、最初に選択肢に気づけることが一番大事だと思います。
そもそも選ぶ中に一番良い選択肢が無かったら
選ぶ、選ばない以前の問題です。選択肢は多い方が良いはずです。
選択肢を増やすには、先輩や自分より優れていると感じている人
の経験談などを聞けばよいと思います。
そうすることで自分がその場面に立った時に、
選択肢が増えているはずです。

次に選び方ですが、
その選択によって今後どのような影響を与えるか
を考えることでよい選択を選べると思います。

その時良さそうなものを直観で選ぶよりも、
この選択によって今後にどのような影響を与えるか
どんな良いことがあるのかを考えるべきです。

難しいことですが、日々より良い選択ができるよう考えながら
生活していきたいと思います。

Javaで遊ぶ ～キーボードでドラムを鳴らそう～

GWも終わってしまいましたね。皆さんはいかがお過ごしでしたでしょうか。
私は久しぶりに学生時代の友人と会ったり、格ゲーのイベントに行ったりとそれなりに充実したGWを送れました。

そんなGWでしたが、暇な日にふと思いついたので一つアプレットを作ってみました。
概要としては、キーボードでドラムを鳴らすお遊びアプレットです。（命名：KeyboarDrum）
また、このブログは初心者の方や、未経験の方もよく見ていただいているとのことなので、なるべくわかりやすいシンプルな内容にするというコンセプトで作ってみました。
といっても私もまだ初心者なんですけどね。
開発環境はEclipse 4.7 OxygenでJavaSE-1.8を使用しています。

import java.applet.Applet;
import java.awt.event.KeyEvent;
import java.awt.event.KeyListener;
import java.io.File;

import javax.sound.sampled.AudioFormat;
import javax.sound.sampled.AudioInputStream;
import javax.sound.sampled.AudioSystem;
import javax.sound.sampled.Clip;
import javax.sound.sampled.DataLine;

public class KeyboarDrum extends Applet implements KeyListener{
	//ドラムの音声ファイルパスとトリガーにするキーの列挙型
	public enum Drum{
		BassDrum("C:\\BD.wav",'f'),
		SnareDrum("C:\\SD.wav",'d'),
		HiHat("C:\\HH.wav",'j'),
		;

		private String path; //オーディオファイルのパス
		private char triggerKey; //トリガーにするキー

		private Drum(String path, char triggerKey) {
			this.path = path;
			this.triggerKey = triggerKey;
		}

		public String getPath(){
			return path;
		}
		public char getTriggerKey(){
			return triggerKey;
		}
	}

	@Override
	public void init(){
		addKeyListener(this);
	}

	@Override
	public void keyTyped(KeyEvent e) {
		// TODO 自動生成されたメソッド・スタブ
		//押したキーは何か取得する
		char key = e.getKeyChar();

		//どのキーが押されたか判定し、対応する音を再生する
		if (key == Drum.BassDrum.triggerKey){ //トリガーキーをfにしているので今回はfキーを押した場合
			//音を再生する
			playSound(Drum.BassDrum.path);
			//ついでにコンソールに出力してみる
			System.out.print("ドン");
		}else if(key == Drum.SnareDrum.triggerKey ){
			playSound(Drum.SnareDrum.path);
			System.out.print("タッ");
		}else if(key == Drum.HiHat.triggerKey){
			playSound(Drum.HiHat.path);
			System.out.print("チャ");
		}
	}

	@Override
	public void keyPressed(KeyEvent e) {
		// TODO 自動生成されたメソッド・スタブ
	}

	@Override
	public void keyReleased(KeyEvent e) {
		// TODO 自動生成されたメソッド・スタブ
	}

	public void playSound(String audioFilePath){
		AudioInputStream stream;
		try {
			//オーディオファイルの読み込み
			stream = AudioSystem.getAudioInputStream(new File((audioFilePath)));

			// オーディオ形式を取得
			AudioFormat format = stream.getFormat();

			// ライン情報を取得
			DataLine.Info info = new DataLine.Info(Clip.class, format);

			// 空のクリップを作成
			Clip clip = (Clip) AudioSystem.getLine(info);
			// クリップを開く
			clip.open(stream);
			//再生する
			clip.start();

			// ストリームを閉じる
			stream.close();
		} catch (Exception e) {
			// TODO 自動生成された catch ブロック
			e.printStackTrace();
		}
	}
}

やっている内容は単純で、列挙型(enum)でドラムを鳴らすにあたっての情報を格納しておき、キーが押されたとき（keyTyped()）どのキーを押したかによって再生処理（playSound()）に渡す引数を決定し、対応している音を鳴らすという内容です。

それで、作ったのはいいんですが、はてなブログに直接動画を貼り付ける機能がいつの間にか廃止になってたみたいなので、GIFで動作を張っておきます（肝心の音が……）

初心者の方やこれから勉強しようと思っている未経験の方は、小難しいことは一旦置いておいて、まずはこういった楽しめるプログラムを作ってプログラミングの楽しさを知るのがいいんじゃないかなと思います。

以上、こういった遊びプログラムでモチベを上げつつ、逐次勉強をしていこうと思っています。

なまけるためにプログラミングをしよう

のっけからなにを言っているだコイツは……な感じですが、システム業界に入ってはや半年、自分がシステムを作る意味について考えたところ、そういうことなのかなぁ、と思うようになりました。

もともとは自分がこの業界へ入ろうと思ったきっかけというのも、
「手に職をつけたい！」
「知らない業界にチャレンジしてみたい！」
という思いがあったからなんですが、そもそも、なぜシステムを作るのかという意味について考えたことはありませんでした。

そんな疑問を持ったきっかけは、上司からの一言でした。
ある日ちまちまと受信メールを手動でフォルダ分けしていた私に、上司がフィルタ機能を使うよう助言してくれました。

「面倒くさいじゃん、それって。代わりにやってくれる機能があるんだから、使うべきだよ」

た、たしかに…
出勤した直後はなにかと細々した作業があるので、メールの整理はできれば排除したいタスクです。
限られた時間の中で最大限のパフォーマンスを発揮するために、使える機能は積極的に使っていくべきですよね。
（メールのフィルタリング機能くらい知っておけという話ですが）

上司にとっては何気なく言った一言かもしれませんが、その時の私はなぜか妙に感激してしまいました。

便利な機能も、だれかがプログラミングしたからあるんだよね。

普段から何気なく使っているソフトやアプリケーションも、作る必要があったから存在するわけです。
例えば給与計算をしてくれるソフトウェア。
給与の計算には多くのデータが必要であり、軽く数えてみるだけでも、
①基本給
②保険料
③各種税金
④諸手当
⑤残業代(割増賃金)
等々が必要です。
これをいちいち手入力していたら、1人の給与計算に30分かかるとして、従業員が100人いては50時間かかる計算です。
日数で丸2日です。その間休みなしです。それってめんどうです。特にデータを入力する時は、100人分のデータを繰り返し行っていくわけですから、いつかは集中力も途切れますし、飽きます。

しかし、それをプログラムにやらせれば、出社時間の入力だったり、簡単な動作だけであっという間に給与計算ができてしまいます。それに、人間がやるよりも正確です。
余った時間も別の作業に割くことができますし、効率も上がります。
システム万々歳！めんどうなことを機械にやらせることで人間は時間を有効に使うことができました。

普段の仕事も真剣に！丁寧に！でも、ラクを考えよう。

私たちがシステム開発をするのも、プログラミングを始めるのも、元を詰めれば「めんどうだなあ」から始まっていたことだと思います。
めんどうなことをプログラムが代わりに処理することで、その分だけ人間は別のことに頭を使えますし、そのめんどうがもっと普遍的なほど、それを解決するプログラムはそれだけ人間をラクさせます。

ある意味、この業界の醍醐味とは、素直さなんじゃないかなぁ、と。

めんどうなことをめんどうなままにせず、解決案を探る。
その為には、普段から行う作業について考える姿勢が必要なんじゃないかと。
この作業ってもっと簡単にできないのか。
こうすればもっとラクにすすめられるんじゃないか。
などですね。上記は日ごろから上司から言われ続けている事でして、ただ命じられたことを淡々とこなすようではモチベーションも上がらないし、ひょっとしたら仕事がつまらないと思うこともあるかもしれません。
普段の業務から「ラクしたい！」なんて考えを持つ人の方が、むしろ仕事の効率を上げられる可能性があるのかもしれません。

いろいろ意見はあるかと思いますが、ここ最近で私がすごく腑に落ちた考え方でした。

唐突ですが、漫画ドラえもんの1コマで、のび太の呟いた言葉がふと蘇ったので、これを締めの言葉とさせていただきます。

一生懸命のんびりしよう

ありがとうございました。

【社内研修】SimpleCode100は面白い

今回はエンジニア向けの研修であるSimpleCode100を終えたので、その感想を書きたいと思います。

まずSimpleCode100とは何かというと、コードを書く力が不足している方を対象に、スキルアップをしようという目的のため作成されました。

名前の通りプログラムの問題が100問あり、参加者が会社に集まり問題をひたすら解いていく研修となります。
言語はJavaかC#を選べます。

私は、シベスピに入社するまでの間にブランクがかなりあったので、研修に参加をさせていただきました。

問題の内容はと言いますと、序盤は簡単な問題から始まり、加減乗除余、文字列操作、配列、ソートなど基礎的な内容でした。
中盤はバッチ、カレンダー、ファイル操作(CSV入出力、iniファイル入出力)など業務で活かせそうな問題が多数出ます。
終盤は、簡易ゲーム制作、クラス作成、ラムダ式、Listクラスの自作を行います。
最終問題は、10択から好きな問題を選ぶことが出来ます。

私の場合、序盤は問題なくスムーズに進みました。
中盤はカレンダー問題で躓き、かなり悩みました。
終盤の簡易ゲーム作成は、解くのが楽しく、過去に制作経験もあってか、サクサク進めました。
反面、ラムダ式とListクラス作成は頭を抱えました…。

ですが、悩んだときも先輩たちが近くにいてくれるので、気軽に質問することができます。

質問に対する解答も、直接答えにつながるようなことを教えてくれるわけではなく、私がどんなロジックで作成しようとしているのかをヒアリングした上で、軌道修正をしてくれるような内容なため、自分で考える力をつけることが出来たと思います。

この研修を通じて学んだことは沢山ありますが、今後私自身の中で特に心がけようと思ったのは下記の2点です。

・プログラムを作成するときは、最小の機能から考えて作っていくこと。
・悩んだとき、詰まったときなどは、もう一度目的(ゴール)を再確認すること。

SimpleCode100は完了しましたが、業務で通用するかといったらそうでは無いので、今回の研修で学んだ事を活かし、さらなるスキルアップを目指してコツコツ勉強していこうと思います。
以上です。