株式会社シベスピ 従業員ブログ

シベスピの社員ブログ。技術・想い・経験沢山書いていきます!

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問あり、参加者が会社に集まり問題をひたすら解いていく研修となります。
言語はJavaC#を選べます。

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

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

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

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

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

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

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

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

デスクトップPCを攻略したい

こんにちは。
会社を良くする会広報チーム・社員ブログ投稿予約担当の松本です。
今月で社会人になって1年になりました。おのれ住民税。
そして入社して1年にもなります。環境も変わり、そのたびに仕事の内容も変わり、まだまだ慣れないことだらけ。
がんばっていきます╭( ・ㅂ・)و ̑̑ グッ !
本日お話するのは、そんな私の目下の悩みであるこちら。

デスクトップPCを攻略したい。

デスクトップのPCを使用するとき、卓上に置くものといえば、
①本体(下に置く場合もありますね)
②ディスプレイ
③キーボード
④マウス
このあたりになると思います。
特にこの③と④の関係が難しい。
キーボードをディスプレイに対して中央揃えにすると、テンキーの分だけ、タイプキーがやや左に寄ります。微妙に打ちにくい……。
だからってキーボードをずらすとマウスが遠くなります。これも若干使いにくい……。
最早左利きになるしか道はないのか……!

ベストポジションを探せ!

今すべきことは我慢ではなく、最適の環境を作ること!
というわけで、早速調査してみました。

フルキーボードで操作する場合

色々なサイトを調査して多かったのが、タイプキーのHもしくはBをディスプレイの中央になるように配置する方法。
実際においてみると……これは打ちやすい!
ほとんどの作業が腕を動かさずに済みますし、やはり中央揃えは偉大な存在です。
気になるのは、やはりマウスとの距離感ですね。次はこちらの配置を気にして調べてみましょう。

マウスを使う場合

テンキーの下(キーボードの手前)が操作しやすいという話を聞いたので、早速実践。
私が使用しているマウスは有線なので、少し再現に手間取りました。無線だと簡単にできそうですね。
肝心の使い心地ですが……ヴーンなるほど。という感じでした。
マウスを持った時に肘が90度になると楽だそうなので、もう少し試行錯誤してみたいと思います。

マウス一体型キーボードを買う

https://www.sanwa.co.jp/product/syohin.asp?code=SKB-TR03BK&utm_medium=Release&utm_campaign=SKB-TR03BK
かっこいい。
一体型は数あれど、手を奥と手前に動かすのは画期的ですね!いつか触ってみたい!

もう小さいキーボードを買う

これかなあ!!

大したことではないかもしれませんが

結局、Hキーをディスプレイの中央に揃えてから、マウスを動かしやすいように微調整することで一旦終了。
完全攻略とは至りませんでした。無念。

PCを使う仕事をしていなくても、触れる機会が多い方はたくさんいらっしゃると思います。
配置を考えるもよし、新しい物を買うのもよし、自分の作業がしやすいように環境を整えてみると、ちょっと調べるだけの作業も、格段に楽に、そして楽しくなるかもしれません!
よいPCライフを(*`・ω・)ゞ



[参考]
https://schoolsidejob.com/life/pc-posture/
⇒正しいパソコン姿勢について!今後のためにも意識していきたいですね。
https://mypage.otsuka-shokai.co.jp/contents/business-oyakudachi/pc-techo/2013/201301.html
⇒マウスの距離感と肘掛椅子の重要性を教えていただきました。肘掛……作るか……?

客観的視点を持つために

出だしから上から目線感満載ですが、躊躇すると何も書けなさそうなので一気に書いていきたいと思います。

「客観的」なもの

客観的なものの代表として「数字」があります。
例を挙げるなら、

 A.1か月で1億円の売上を上げた会社
 B.1か月で5千万円の売上を上げた会社
 
 C.2017年に資格を1つ取った社員
 D.2017年に資格を3つ取った社員

などです。
誰が見ても明快で変わらないものですね。

ここで上記のAとB、CとDそれぞれの優劣について評価するとします。
この段階で客観的な評価をすることができるでしょうか。

客観的な評価をするために必要なこと

客観的な評価をするためには、客観的な情報を十分に収集し、それらを客観的に分析する必要があります。
上記の例ではまだ情報が不足しています。
例えば以下のようなものです。

 AとBの場合:社員数や利益
 CとDの場合:資格の内容、資格を取るために掛けた時間
 
評価に必要な情報が揃っていないのであれば、それらを集めなければなりません。
集めるための手段を検討し、実行して情報を集めます。
集めていない段階で評価してしまうと客観的な評価にならず、その評価を基準に行動してしまうと良からぬ結果につながるリスクが高くなってしまいます。

客観的な評価を妨げるもの

客観的な評価を妨げる代表的なものが「感情」です。
怒ったり悲しんだりというのはその人に属するものなので、それらを評価基準に含めてしまうと主観的な評価になり、それをぶつけ合うと喧嘩に繋がる恐れがあります。
言い換えれば、客観的な意見同士のぶつけ合いであれば、喧嘩に発展する可能性はほぼないでしょう。

最後に

 ①客観的な情報が十分に集まっているか
 ②自分が感情的になっていないか
 
この2点を常に顧みながら物事を評価したり、人とコミュニケーションを取ったりすることで客観的な視点を養っていくことができると思います。
ビジネスにおいて客観的な視点は必要不可欠です。
物事を客観的に見ることが苦手な方は、まずは自分自身を客観的に見る(=自分に関わる数字を集めて評価する)ことにチャレンジしてみてはいかがでしょうか?

ちょっと息抜き?社内イベント!

久しぶりの投稿になります、鎌野です。
入社してから早11ヶ月・・・。あと少し(4月)で1周年になります!!!
(この記事が投稿されるときには、1周年を迎えているかもですね。)
ここまで長かったような、短かったようなと不思議な気持ちです。

仕事は忙しい時期もありモチベーションを保つためにも息抜きは重要なことだと思います。
仕事仕事仕事仕事仕事仕事仕事休み仕事仕事仕事仕事仕事仕事仕事仕事仕事休み仕事仕事仕事仕事仕事仕事仕事仕事仕事休みか?仕事仕事仕事仕事仕事仕事仕事という毎日を送ってしまうと気が滅入ってしまいます。
仕事が終われば楽しいことが待っていると思うと、頑張れますし、気持ちの切り替えになります。

ここで自分がこの1年シベスピに入社してからのイベント関連について私視点でいくつか紹介したいと思います。

お花見(4月)

桜が咲き始めると、どこからともなく「お花見」の話が上がってきます。
定時後に近くの公園で花見の開催です!
コンビニで食べ物・おつまみ・お酒を買い込み、ワイワイ楽しく飲みます!
途中、ピザの出前を頼んだり、足りなくなったお酒を買いに行ったりと普段の飲み会とは違った楽しさがありました。
お酒、おいしいです。

バーベキュー大会(6月)

気温もあがってきて、暑くなってきたこの時期、土曜日にバーベキュー大会が開催されました。
赤羽岩淵にある公園で食材・お酒を大量に買い込み、焼きはじめます。
お昼からの開催、気温が暑くなってきたということもあり、食(主に肉)とお酒が進みます!
普段社外に出ている人とも交流を深めることができ、充実した1日でした。
お酒、おいしいです!

社員旅行(9月)

今年は2泊3日でマニラに行きました!(前年は滋賀だったそうです。)
私自身、アジアに行くことは初めてだったので目新しいものがいっぱいでした。
それぞれ、市街観光・マリンスポーツ・カジノといったことを楽しんでいました!
私はカジノ・マリンスポーツ・銃の実弾を撃ちに行ったりしました。
残念ながら、カジノでは負けましたw ※もちろん、勝った人もいますよ!
全員でマニラのお店で食事もしたりしました。
お酒、おいしいです!!

納会(12月)

年末ということで、毎年恒例の納会が開かれました。
池袋の「月亭」というお店でしゃぶしゃぶを堪能しました。
ご家族がいらっしゃる方は家族の方も参加可能で、一年の締めくくりを全員で楽しみました。
お酒、おいしいですw

まとめ

いかがだったでしょうか?
大きいイベントだけをいくつか紹介させてもらいましたが、小さいものを入れると数え切れません。
私は飲み会の回数も以前より大分増えました。
週中であるにもかかわらず、終電を過ぎて深夜2時くらいまで飲んでいるということもあったりしますw

しかし、こんな楽しいことがあるからこそ仕事も楽しく、モチベーションも保つことができると思います。
仕事と遊びの切り替えは大切だと思いますので、メリハリをつけましょう!

最後に、私はお酒がそこまで強くありません!

保守のお話

エンジニアという職業につかせていただいてから保守をメインにやってきました。
なりたてのころは、エンジニアとしての仕事が出来るようになった!わーい!という感じだったのですが、しばらくするとエンジニアと言っても開発や運用や保守って業務分かれているのか!と知り、少し大人になった気がしたのも最早5年前。。時が過ぎるのは早いものですね。

まぁ、そんな話はさておき、現在共に保守を担当しているメンバーの中には新人さんもいるので、今回は保守の魅力を書いていきたいと思います。

まず保守って何。

会社さんによっても内容はまちまちではあると思うのですが、私の経験してきた業務の範囲でざっくり言うと、開発工程で作られたシステムが実際稼動し始めた後に、追加で必要な改修があったり、障害が起きた場合に、もう動いちゃってるシステムの改修をするのが今回私が言う保守業務になります。

ここが怖いよ。保守業務。

保守業務の一番のポイントは、やはり「もう稼動しちゃってる」って所に尽きるかと思います。稼動前にバグが出ようが稼動までに直せばいいのですが、もう稼動してしまっているシステムにバグなんて仕込んでしまうと最悪そのシステムを利用している業務がとまってしまう。これがECサイトとかの場合、わかりやすく言えば営業停止状態になってしまう(=その日に売り上げる予定だった利益がすべてなし)。自分の書くたった1行のコードにミスがあった、自分の作成したテスト仕様書に1つ漏れがあった。ただそれだけでも、担当している内容によっては大事になりかねない危険性を秘めているスリルにあふれる業務だったりします。

だからこそ鍛えられた。①調査編

そんなスリルと隣り合わせな中で、一番最初に立ちはだかるのが、まずは他人の書いたコードを理解するということ。設計書とかのドキュメントが整備されている環境ならまだ良いのですが、それでもコードは読まなければいけません。自分の書いたコードだって、半年経てばなんだこれってなるのに、他人の書いたコードなんて。。しかもだいぶ長く稼動していたシステムの場合、障害対応で応急処置したものがそのままなんてことや、コメントと書いてること違うなんてざらにあるため、まぁ、読むのが大変。そんな中で障害の原因をいち早く突き止めたり、改修する場所を見つけなければならないことから、読解能力は身につきます。また、読んでいてわかりにくいとか、なんだこれとか思うこともあるにはあるので、アンチパターンも自然と覚えます。

だからこそ鍛えられた。②製造・テスト編

製造1割、テスト9割。工数の割合的に私はこう育てられました。これが何を意味するか、もちろん障害なんてものによってはそんな余裕持った工数なんて取れません。つまりは、さっさと直してテストしろってことなんですね。1割の中で当然ですがバグなんて埋め込まず、その上でテストをしやすいコードを書くことを求められるわけで。。いや、正直ぱっぱらぱーの右も左もわからないときはめちゃくちゃつらかったです。しかしそれがあったからこそ今があるといえるのも確かでして、そういったスピード感も身につきます。また、テストの観点としても、必要最低限ぎりぎりを攻める勘所というのは保守だと身につきます。(私は未だにケースをつみすぎる傾向にあるのですが、すごい方は綺麗にぴしゃっと決めるので早くそうなりたい。。)

だからこそ鍛えれられた。③精神編

障害が発生した時。ましてや自分が改修した内容でバグを出したりしたら等、予想外の動揺せざるおえないことに対して、自分の感情をコントロールして、まずは問題解決に向かうというスキルは身につきます。実際、去年プライベートで大変なことがあったのですが、冷静に対処できたのは保守を経験していたからだと思っています。
また、これは製造の話にもなるのですが、プログラミング覚えたてってやっぱ書きたいではないですか。私もそんな時代を経験しているのですがそんな時、「バグを生まない方法って何だと思う」と聞かれたことがありました。答えは「プログラムを書かないことだよ」と。エンジニアが何を言っている、それが仕事だろうと思われる方もいるかもしれないのですが、システムエンジニアはあくまで仕組みを提供する技術者であり、プログラムを書くのは手段の一つだと、プログラムを書くことが本当に利用する方や業務の目的なのかと。実際ユーザーの要望にこたえて、改修を行っても使われない機能も見てきました。そういったことを考える機会に出会えるのも保守をやっているからこそかと思っています。

締めとして

保守は大変ですけど面白いです。私なんてまだまだな身分でこんなことを書くのかって石投げられそうでびくびくしているのですが、楽しいことを伝えたいと思って書きました。
余談として、今までの保守で見てきた中で、一番ひどい変数名はunkoでした。保守って面白いですよね(違)