2014年9月21日日曜日

「仕事の話はすんな」ってマジ?

仕事終わりの飲み会とかすると、タイトルに書いたような発言が聞かれます。
※追記:ここでの飲む相手は仕事仲間とは限らずに書いています。

…なんで?


・社外で話すのは、社内規則に反するから
これは分かる。
守秘義務とか色々あるからね


・せっかく会社から離れたんだから、仕事のことは考えたくない
ホントにそうなの?
仕事が楽しいと思ってれば、社外に出ても話したいし、楽しくなければ愚痴の一つは言いたくなるもんじゃないの?
追記:愚痴ばかり聞く状態になるのは確かに嫌です。


・訳の分からない専門用語とか技術用語を聞きたくない
知らないことを聞くって良い刺激にならない?
分からないけど面白そうだったら後で調べれば良いだけだし


辛いのを会社外にまで持ち込みたくない気持ちは分からなくもないが、それって現実逃避してるだけじゃない?
自分が力不足だと認めた上で色々と仕事の話をするのも楽しいと思うんだけどな…。


…とか書いてると「お前と飲みたいと思えねーわ」って言われそう

2014年9月13日土曜日

ソフトウェア品質シンポジウム(SQiP)2014に行ってきました(基調講演編)

9/11・12と、ソフトウェア品質シンポジウム(SQiP)に行ってきました。

「シンポジウム」とか聞くと、お堅い印象を持たれるかもしませんが、全然違った!!
特にお堅い印象を無くしてくれたのが、基調講演2つ。


基調講演その1『ビジネスが変わる・・・品質が変わる』
(横塚裕志氏 東京海上日動システムズ(株)顧問)


ね、一見すると「ちょっと堅そう」でしょ?
だって「顧問」のお出ましですよ?


ただ、中身は全然違う。
時代に合わせた柔軟な発想でした。
むしろ、聴講者達は、「自分の考えは全然追いついていない」と感じてしまったんじゃないでしょうか。

「時代が求めている品質は、
(トラブル/生産量)の極小化
ではなく、
(効果×スピード/生産量)の極大化
である」

という言葉は、色々な例も踏まえると非常に納得出来ました。
例えば新聞記事とか。
昔…誤字などを気をつけて、記事の質を高める
今…質よりもスピード

ただ、納得しつつも、組み込み系やエンタープライズ系は対応しきれていないのも事実。



基調講演以外の発表などを聞いていても、「組み込み系やエンタープライズ系」と「コンシューマ系」で品質に対する定義が違っているように感じました。

それは、楽天の荻野さんの経験発表(スライドはこちら)冒頭での「基調講演の発表内容が当たり前だった自分にとっては皆さんの反応が意外だった」という発言が物語っています。




基調講演その2『リスクマネジメントのための失敗学---再発防止と未然防止---』
(濱口哲也 東京大学大学院特任教授)

ね、こっちも一見すると「堅そう」でしょ?
だって「東大大学院教授」のお出ましですよ。


「どんな人だろう…?」とか呑気なことを考えていたら始まったマシンガントーク!!!
あっっっっっっっっっっっっっという間の1時間でした!!!


そして気付かされました。
お堅いのは、講演内容ではなく会社のマニュアルだったんですね。


例えば、会社のマニュアルでは
1. Aをやりなさい
2. Bをやりなさい
3. Cをやりなさい
4. Dをやりなさい
と書いてあることが多くて、
1. AとBとCをやりなさい
2. Dをやりなさい
と書いてあることは少ない。

一般的には前者の方が良いとされているけれども、下の方が適切なんだな、と。


実は「見直そう!開発文書のあるべき姿」というSIGに参加したんですが、その時には、
「手順やif分岐をつらつらと文章で書かれても、読む方は辛い」
という意見が出ていました。


基調講演2の話をまとめると次の2つ。
1. 失敗したら、言い訳を残せ
2. 「つまり」を使って上位概念化せよ

そして、昨日、家に帰ってきてニュースを見てたら、こんな記事がありました。
カテーテル誤挿入で患者死亡=マニュアル熟読せず―名大病院

記事内には
記者会見した石黒直樹院長は「深く反省している」と述べ、マニュアルの順守を徹底させるなど再発防止に努める考えを示した。
と書いてあり、
マニュアルがあってそれを熟読しないってどういうこと??
とコメントで書かれていました。

きっと昨日の基調講演2を聞いていた人は、このニュースに対する考え方が違うんではないかなと思いました。


2014年8月17日日曜日

コミケ86の戦利品

半年恒例の戦利品晒しの時期がやってまいりました。

戦利品全体はこんな感じ。

今回も1サークルずつ紹介していきます。


2014年6月1日日曜日

JenkinsでMavenのERRORのみを記載したメールを飛ばそう

前回、若干AWSなどに触れていることを書きましたが、今回はJenkinsのお話。
(こうやって普段使っているものを書いていくと、だんだんバレてしまうのではないか、と思ったけどどうせ名前もバレてるんだからいいか)


Jenkinsは非常に役立っています。
Jenkinsを使うと、自動でコンパイルを行ってくれます。

Jenkins


「コンパイル?そんなのローカルPCのコマンドプロンプトやEclipse上で行えばいいじゃん」
と思っている人がいるかもしれません。

しかし大人数で開発を行っている場合、個人の設定で左右されてしまうローカルPC上でコンパイルすることはあまり良くありません。
例えば、みんな同じVersionのJDKを使っているという保証はありますか?
ライブラリのパスをローカルPC上の絶対パスで指定していませんか?


こういうことを無くすために、現在、私の部署ではJenkins&mavenを利用してコンパイルしています。
ただ、Jenkins&mavenでコンパイルすると、大量のログが出てきます。
このログをただ単にメールへ載せると、メール本文が大変なことに…!


ということで、今回はJenkinsでコンパイルエラーによるJob失敗が起こった時に、ERRORのみ記載したメールを飛ばそうというお話です。


2014年5月11日日曜日

命名規則についてのお話

先月で、新卒で入社して1年が経ちました。

自分の入った会社はルールにあまり厳しくなく、自分が考えた物事に対して、結構自由に動くことが出来ているので、楽しく仕事ができています。


ただ、自由過ぎるが故に、部署内(あるいは社内)に命名規則がないということに困っています。
困る、というよりも泣きそうです(ノД`)



皆さんの会社では、以下のようなものに関して、命名規則がありますか?
1.社員用メールアドレス
2.取引先の会社名
3.サーバの名前(AWSなどのクラウドのインスタンスの名前)


これらに関して命名規則がないと、実は管理上すごい困ります。
もしも命名規則が存在していない場合は、被害が小さい今のうちに命名規則を作るべきです。


そして、実は自分が働いている会社・部署は、上記のものの命名規則が存在していません。(もしくは後追いで作られた)


なにせ、新卒で入った初めての会社なので、他の会社はどんな感じなのか知りませんが、これらに苦労することがあったので、それぞれについて詳細を書いていきます。
(これらに関して命名規則がない方がおかしい!とかあったら教えて下さい)




2014年2月23日日曜日

String.splitで標準入力された文字列から改行コードによってStringの配列に分けるコードについて

今回はJavaについてのお話。

今回やりたかったこと
条件:入力を「◯◯\r\n△△\r\n□□」とする。
結果:以下のように表示される。
◯◯
△△
□□
考え:「\r\n」を認識して、String配列に変換できれば良いかな…?

ということで、こんなコードを作ってみます。
Wrong.java
class Wrong {
    public static void main(String[] args) {
        String[] sentence = args[0].split("\r\n")
        for(int i=0;i<sentence.length;i=++){
            System.out.println(i + 1 + "行目は " + sentence[i] + " です");
        }
    }
}
そして、これに、
java Wrong 最初の行\r\n次の行\r\n最後の行

と入力すると、

1行目は 最初の行\r\n次の行\r\n最後の行 です。

と表示されてしまい、残念ながら、文字列の分割が行われず…。
ということで「きっと『\』をエスケープしてないことが原因なんだ!」と思い、リトライ。
Wrong.java
class Test {
    public static void main(String[] args) {
        String[] sentence = args[0].split("\\r\\n")
        for(int i=0;i<sentence.length;i=++){
            System.out.println(i + 1 + "行目は " + sentence[i] + " です");
        }
    }
}

こうすることで、きちんとエスケープされて「\r\n」と認識してくれるはず…!
と思ったけど、またしても
1行目は 最初の行\r\n次の行\r\n最後の行 です。

と表示されてしまい、失敗。

デバッグで一つ一つ見ていくと、標準入力された「\r\n」はエスケープされ
「\\r\\n」としてargs[0]に入力されるらしい。
その「\\」をそれぞれエスケープしないといけないので…
Correct.java
class Correct {
    public static void main(String[] args) {
        String[] sentence = args[0].split("\\\\r\\\\n")
        for(int i=0;i<sentence.length;i=++){
            System.out.println(i + 1 + "行目は " + sentence[i] + " です");
        }
    }
}

とすることで、きちんと、
1行目は 最初の行 です。
2行目は 次の行 です。
3行目は 最後の行 です。

となってくれました。

2014年2月11日火曜日

PlayFrameworkでサニタイズから逃れる方法

先日に引き続き、PlayFrameworkの話です。

PlayFrameworkを使っていて、便利だが困ることが一つ。
それは、自動的にサニタイズされてしまうという点。

例えば、

controllers/Application.java
package controllers;

import play.*;
import play.mvc.*;

import views.html.*;

public class Application extends Controller {

    public static Result index() {
        return ok(main.render("'hoge'"));
    }

}


view/main.scala.html
@(autoEscape: String)

<!DOCTYPE html>

<html>
    <head>
        <title>テスト</title>
    </head>
    <body>
        @autoEscape
    </body>
</html>

というコードがあったとすると、実際にmain.scala.htmlに入るautoEscapeには、
「'hoge'」ではなく、「&#39;hoge&#39;」が入ってしまいます。

もちろん、<html>タグの中なら勝手に判断してくれるので、別に問題はないのですが、
例えばview/main.scala.htmlの中に<script>タグを置き、その中に@autoEscapeを
持ってきて処理したい場合は、ちょっと困る。
なぜなら、<script>タグの中では上手い具合に判断してくれないから。

このような事態の回避方法を調べても、ほとんどのサイトで出てくるのは、
「.raw()を使え」という言葉ばかり。

特に、引数で持ってきた値をエスケープさせないで使う方法が書いてない!!!


ということで、辿り着いたページがココ↓
Stack Overflow - How to pass raw html to Play framework view?

そして試してみたのが以下の書き方。
@(notEscape: String)

<!DOCTYPE html>

<html>
    <head>
        <title>テスト</title>
    </head>
    <body>
        @Html(notEscape)
    </body>
</html>

このように、 @html(引数名) と書くことで、「'hoge'」という記載で通ってくれるよ!
やったね!

と思ったら、ちゃんと以前紹介したサイトにも書いてありましたorz
ちゃんと読もう、自分。
@IT - Java開発者がScalaでPlay frameworkのビューを作るには (2/3)