エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

【書評】理科系の作文技術

理科系の作文技術(リフロー版) (中公新書)

理科系の作文技術(リフロー版) (中公新書)

目次

  • 序章
  • 準備作業(立案)
  • 文章の組み立て
  • パラグラフ
  • 文章の構造と文章の流れ
  • はっきり言いきる姿勢
  • 事実と意見
  • わかりやすく簡潔な表現
  • 執筆メモ
  • 手紙・説明書・原著論文
  • 学会講演の要領

感想

あくまで個人が呼んで解釈した内容。
実際にかいてあるわけでは無い。
個人の主観も一部混じっている。

準備作業(立案)

理系の文章

理系の文章は、必要上かくか、書かされるもののどちらかにあたる。
だから、書き始める=理論的推察は完了し、書くために必要な材料は揃っているハズ。
材料がない場合は、そもそも各段階にまで至っていない。 始めても失敗するだけなので、書き始める前に、必要な材料があるかは確認する。

理系の文章は、必要とされるから書くため、読み手(書けと支持した相手)が何を欲しているのか考える必要がある。

主題の選定

主題で、文章が有意義になるかが決まる。 下記のポイントを考慮する。

  • 議題は明確か?
  • 一文章一主題になっているか?
  • 長すぎてないか?(ラノベタイトルみたいになってないか?)
  • 読み手の能力を意識した内容
  • 生の情報
    • 自信の考えがあるか?
    • 未熟・浅薄でもオリジナリティは強力

材料となるもの

  • 思いついたままのメモ
  • 5W1Hの情報
  • 図・表
  • 文献

文章の組み立て

  • 起承転結
    重要なことは後で主張
  • 重点先行主義
    重要なことは戦闘で簡潔にまとめて、目に付きやすくしてある。
    新聞がこの手法で書かれていることが多い
  • 序論・本論・結び

パラグラフ

パラグラフとは、文章の段落のこと。
バラグラフを満たす条件は、トピック・小題について、一つの意見を述べてあること。

はっきり言いきる姿勢

日本人が明言を避けたがるのは、文化・環境の違い。
異民族が少ないので、自己の主張を強くするより、相手の主張を取り入れたように見せる動きが長年続いたから。

あいまい言葉は、逃げ道なので、なるべく使わない。
一言一句、責任を持って表明することが大事。

事実と意見

事実とは、証拠による裏付けができるもの。
意見とは、人が下す判断。

レポートを書く際は、意見ではなく、事実を書くことが必要になる。

意見の概念

  • 推論
    前提にもどつく推理の結論
  • 判断
    物事のあり方、内容、価値を見極めた考え
  • 意見
    自分が考えて到達した結論
  • 確信
    疑問の余地がない考え
  • 仮設
    真偽は明確ではないが、仮に出した考え
  • 理論
    証明できそうな事実はあるが、万人に容認させられていない考え

事実の記述で注意すべきこと

  • 本当に必要なものか?
  • 明確に書く
  • 名詞と動詞で書き、修飾子は避ける。
    なぜなら、就職後に意見が混入しやすいから

わかりやすく簡潔な表現

文は、なるべく短く書くようにする。
長い文章は、誤読を招きやすく、読みにくい。

短く書くときの心得

  • 書きたいことを1つずつ文にする
  • 一文の前後関係を考慮してつなげる
  • 主語をはっきりさせる。

簡潔に

簡潔に書くとは、単に短く書くことではない。
必要なこと以外を書かないようにすることである。
一語一語に役割を必ず持たせる。

読みやすさへの配慮

字面の白さ

漢字の濃度を気にする。
漢字は、たしかに見たときにイメージしやすいが、多用すればいいというわけではない。
情報過多を引き起こすため、使う場所は気をつける。
個人的には、接続後に使うのは辞めたほうがいい気がする。
~の為、~故とか。
中二病をこじらせ中かな?って思ってしまう。

漢語・漢字

難しい漢字は、なるべく使わないほうが読みやすい。
(「憂鬱」は、難しい漢字に入るのか、疑問。)

受け身の文

少ないほうが文が短く、主語が明確になる。

並記の文法

並べてくことは、読者に同格の内容が続くことを知らせる。
そのため、予見して読むことができるので、読みやすくなる。

文章の中の区切り記号

  • ピリオド
    文章の終わり
  • コンマ
    読点
  • セミコロン
    文章の終わりを強くアピる
  • コロン 詳細の要約・説明に使うことがある
  • なかぐろ
    並列連結を表す
  • ダッシュ
    コロン、カッコの代わり。説明に使う
  • リーダー 以下省略
  • カッコ

文末の述語

「である」より、「だ」の方がいい。
「である」は、表現的に固い。

執筆メモ

メモを書くときに必要なもの

  • 日付
    いつ書いたのかが重要になることがあるため
  • 辞書
    言語の厳選をするため。ポケモンの厳選よりは楽。
  • 単位・量記号
    共通認識確率のために、なるべく書く
  • 文献引用
    出所を明示しておかないと、あとで著作権の問題になるから。

全体感想

かなり前に書かれたせいか、表現が堅苦しい&コロン・コンマが凄く見づらい。。。
内容自体はいいんだけど、現代用に変えた方がいいのでは無かろうかと思う。
やっぱり、縦書きだろうが横書きだろうが、句読点は「。」「、」の方が見やすい。

執筆メモのあたりは、たしかにそうだけど、実践が難しいって思った。
ぶっちゃけ、メモなんてほとんど取らんしな。。。
もっと使いやすいメモ帳があればいいんだけど。。。
誰か出してくんないかな?
Evernoteだと、有料になっちゃったし、使いたくないんだよね。。。
文房具で、何か決定的なメモアイテムが欲しい。

Firefox54 アップデート機能内容まとめ

Firefox 54 for developers - Mozilla | MDN

提供開始日

2017 年 6 月 14 日

更新内容

公式サイト

詳しくは、公式サイト見たほうが正確

https://www.mozilla.jp/static/images/firefox/logos/header-logo-wordmark.png

目立った変更内容

Electrolysisが全ユーザーに対して有効化

条件を満たしていればデフォルトで有効化されるが、対応してないアドオンが一つでもあると無効になる。
自分は無効化されてしまいました。。。

確認方法は、Firefoxのアドレスバーに「about:support」と入力し、トラブルシューティング情報のページを開く。
※もしくは、メニューの「ヘルプ」→「トラブルシューティング情報」からでも可。
マルチプロセスウィンドウの項目が “0” でなければ有効になっている。

どのアドオンが問題になっているのかを確認するには、「Add-on Compatibility Reporter」を使って確認できる。

Add-on Compatibility Reporter :: Add-ons for Firefox

詳しいやり方は、下記のサイト参照

Firefox 54で全ユーザー向けに導入されたブラウザ高速化技術「Electrolysis」がオンにならない場合の対処法 - GIGAZINE

今回のリリース

マルチプロセスが目玉みたいだね。
メリット享受できてないのが痛い。。。
早めになんとかしよう。

参考サイト

コンテンツのマルチプロセス化を初めて導入した「Firefox 54」が正式版に - 窓の杜

マルチプロセス技術「E10S」を導入した「Firefox 54」リリース | OSDN Magazine

Firefox 54がリリース - 高速なマルチプロセスモデルへの移行が完了

魔が差す心理的なきっかけ

きっかけ

下記のサイトを見て、チームビルディングについて改めて考えさせられた。
思ったことをちょっとまとめてメモっておく。

www.lifehacker.jp

哲学

「高潔さとは、誰も見ていないときも正しいことをすることだ」-C.S.Lewis(イギリスの学者)

開発している最終は、誰かに見られていないことのほうが多い。
もちろんレビューとかあるけど、レビューする前に精度が高いもののほうがいいハズ。
精度が悪い状態でくるのは、個人的には、魔が指す要素もある気がしている。
誰も見てないところで、適切に開発を行うことが、エンジニアに必要なのでは?と読んでいて思った。

魔が差す

気の迷いによりどのように道徳的指針を失い、道を踏み外す説としては下記の内容がある。
組織を作る場合は、下記を考慮して、人をまとめる必要がある。
※自分流に理解しやすいように、リンクの内容とは少し変えてる。内容は一緒。

  1. 補償作用
  2. 深刻さをちゃかす表現
  3. 認知的不協和
  4. 割れ窓理論
  5. 目標達成圧力
  6. ピグマリオン効果
  7. 同調プレッシャー
  8. 権威に対する服従
  9. 勝者総取り方式
  10. 権力に目がくらむ
  11. 衒示的消費
  12. 些細な盗みの看過
  13. リアクタンス理論

補償作用

補償作用とは、不快感を払拭するための代償的な心理作用のこと。
例えば、1週間ランニングしたから、ご褒美としてケーキを食べるスイーツ女子の考え方がそうである。
気の緩みを起こさせないような制度設計をしておかないと、人はすぐに怠けてしまい、魔が差しやすい。

深刻さをちゃかす表現

表現の仕方が不適切であるがために、人し齟齬を起こし、結果として反倫理的な行動に繋がる。
方針等の重大な内容の告知は、表現を適切にしておかないと、悪用する輩が増える。
聴衆の立場をよく考えた上で、表現方法を考える必要がある。

認知的不協和

自分の心情に反しているけどやらねばならない行動をすること。
最終的に、行動と信条の不協和音から、破滅に至る。
ドラマでよくある魔が差すきっかけ。
指示を出す時は、その人の信条が何なのかを考えて、指示出しする必要がある。

割れ窓理論

混乱や無秩序があると、反倫理的なことを起こしやすくなる現象。
ソフトウェアの世界でもよく言われる。
バグ・エラー・警告を放置しておくと、最後に痛い目を見るのは、どこでも一緒である。

目標達成圧力

目標達成のために、思いやり・倫理的観点が欠落した行動を取ってしまうこと

ピグマリオン効果

他人からの扱いに応じた振る舞いをする傾向のこと。
血液型性格診断がコレにあたると思われる。

囚人と看守の役割期待が有名

同調圧力

所属するグループがとる反倫理的な行動に参加してしまうこと。
その行いに対し、大目に見る傾向が強い。グループの中で孤立するリスクも内包している。

孤高の存在である俺には、あまり脅威ではない。

権威に対する服従

権威ある人の指示は、無視しにくい。
また、自分の意志で行動するわけではないので、罪悪感が薄い。

上司からの命令が間違っていると分かっていてもやってしまうことはある。
あえて使うこともあるのではなかろうか?上司を辞めさせたいときに。

勝者総取り方式

勝者がすべてを持っていくやり方。
このやり方をやっていると、敗者になる人は、不正をしてでも勝とうとするので、いい結果にはならない。
一社独走態勢になれば、周囲から盗作されるリスクも高まるし、一回のミスが大事に取り沙汰されることもある。
また、競争相手がいなくなれば、勝者総取りの価値もなくなる。
独占禁止法は、存在しなければ、魔が差すきっかけができやすくなるとも言えるのではなかろうか?

自分の価値を認められていると、忠誠心が強くなるが、疑心の目を向けられると、回避するために反倫理的な行動になりやすくなる。
絆は、いいことだと思っている輩もいるが、魔が差すきっかけにもなることには注意しなければならない。
結局のところ、絆を作るのはいいが、個々人でも倫理観はしっかり持ち、ダメならダメと言う必要がある。

権力に目がくらむ

権力のある人は、優れた特殊な存在だと思いがちで、他人が持っている倫理基準より甘い行動を取りやすくなりがち。
結果として、それが不祥事に繋がったりする。

散財

財力を派手に見せびらかすと、身勝手な度合いが強くなる。
結果として、欲望を優先させて動くようになる。

些細な盗みの看過

ささいな盗みを許容すると、限度なく膨れ上がる現象。
ささいな罪でも取り締まる必要がある。

リアクタンス理論

人は自由を好む。遵守すべき規則が厳しすぎると、規則を破ることが多くなり、規則が機能しなくなる。

まとめ

魔が差さないようにするのは、結構しんどい。
小さくても組織を作る際は、魔が差すきっかけがどこにあるのか、把握している必要性を感じた。

【用語】Rust 情報メモ

Rustとは

Mozilla Foundationが中心となって開発したOSS
可能な限り抽象化のコストを下げるように設計されている。

特徴

  • ゼロコスト抽象化
  • ムーブセマンティクス
  • 保証されたメモリ安全性
  • データ競合のないスレッド
  • トレイトによるジェネリクス
  • パターンマッチング
  • 型推論
  • 最小限のランタイム
  • 効率的なCバインディング

特徴メモ・解説

トレイトによるジェネリクス

トレイトとは、型が提供する機能をコンパイラに伝える機能のこと。
それをジェネリクスに適用している。
Javaをやっている人からすると当たり前に感じるかもしれない。

採用例

Servo

Mozilla Researchによって開発が進められている新しいWebレンダリングエンジン。
長期的なロードマップとして、Firefoxで採用されているレンダリングエンジンGeckoを、徐々にServoのコンポーネントに置き換えることが計画されている。

関連サイト

プログラミング言語Rust

プログラミング言語 Rust

Google Error Proneのサンプルを動かす

Error Proneとは

Google の バグチェックツール。
FindBugsみたいなもんといえば、Javaエンジニアなら想像しやすいはず。

環境情報

必要なものは、JavaとGradleだけあれば、とりあえず大丈夫

Java

Java9の調査をしてたので。。。
切り替えるの面倒だったから、Java9で試したが、Java8でもイケるハズ!
試すの面倒くさいからしないけど。

>java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+171)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+171, mixed mode)

Gradle

gradle -v

------------------------------------------------------------
Gradle 3.5
------------------------------------------------------------

Build time:   2017-04-10 13:37:25 UTC
Revision:     b762622a185d59ce0cfc9cbc6ab5dd22469e18a6

Groovy:       2.4.10
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          9-ea (Oracle Corporation 9-ea+171)
OS:           Windows 10 10.0 amd64

eclise

Eclipse Java EE IDE for Web Developers.

Version: Neon.2 Release (4.6.2)
Build id: 20161208-0600

とりあえず開発はコイツを使う。
コイツにGradleのプラグイン(たぶんBuildship Gradle Integrationだったと思う)を入れてテスト

試す

とりあえず、今回の目標は、exampleで提供されているものを実行してエラーになることを試す。

Gradleプロジェクト作成

eclipseから新規Gradleプロジェクトを作成

build.gradle を変更

下記リンク先のソースに置き換えれば大丈夫のハズ。

error-prone/build.gradle at master · google/error-prone · GitHub

念のため、自分が使った内容を晒しておく

// See https://github.com/tbroyer/gradle-errorprone-plugin
buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath 'net.ltgt.gradle:gradle-errorprone-plugin:0.0.8'
  }
}

apply plugin: 'java'
apply plugin: 'net.ltgt.errorprone'

repositories {
  mavenCentral()
}
configurations.errorprone {
  resolutionStrategy.force 'com.google.errorprone:error_prone_core:2.0.19'
}

サンプルソースの配置

Gradleでプロジェクト作ったら、Library.javaみたいなソースがあったので、それは消した。
そんでもって、下記のファイルを配置した。
どこでもいいと思うが、例にならって、src\main\java\Main.javaに配置した。

error-prone/Main.java at master · google/error-prone · GitHub

/*
 * Copyright 2013 Google Inc. All Rights Reserved.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

public class Main {
  public static void main(String[] args) {
    // Dead exception
    new Exception();
  }
}

FindBugsやってなくても、コレは「変」って分かるはず。
Exceptionをthrowしてないって。

実行

Gradleを clean & build !
そうすると、下記のエラーが出てくるはず。

..src\main\java\Main.java:20: エラー: [DeadException] Exception created but not thrown
    new Exception();
    ^
    (see http://errorprone.info/bugpattern/DeadException)
  Did you mean 'throw new Exception();'?
エラー1個
 FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileJava'.
> Compilation failed with exit code 1; see the compiler error output for details.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 0.841 secs

たぶん、意味的に「new Exception();っておかしくね? throw new Exception();がやりたかったんじゃね?」ってことを行っていると思う。(銀魂風に翻訳してみた!)

感想

なんとかサンプルを動かすまでできた。
Gradleの存在は知っていたけど、使い方は知らなかったので、かなり手間取った。

あと、日本語の情報が異様に少ない。
みんな、FindBugsを使っているのかな?

コンパイル時に弾かれるから、直さないとUnitテストもできないので、かなり強制力が強い気がする。
※もしかしたら回避できるかも知れないが、俺にはここまでの実力しかないようだ。。。

ルールをカスタマイズしたりできるらしいが、ぶっちゃけよく分からん。
英語に対する苦手意識が強い。
FindBugsが本格的にダメになってきたら、ガンバってドキュメント読んで見る。
もしくは、誰か翻訳してぇ~
Google先生に翻訳お願いするしかなくなる。

今後のTODO

ルールのカスタマイズ

参考リンク

ksby.hatenablog.com

Error Prone

Installation

java9 Jigsaw 試し実装

きっかけ

Java Day Tokyo 2017, JJUG CCC Spring 2017 に出て、そろそろJigsawをキャッチアップしねぇと不味いなと感じ、とりあえず触ってみた。

環境情報

Microsoft Windows [Version 10.0.15063]

javaのバージョン

>java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+171)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+171, mixed mode)

コンパイラのバージョン
必要かどうか迷ったが、最初に入れたときにコンパイラバージョンがJava8のままで、module-info.javaが怒られて、結構迷うという恥ずかしい事態になったので、気付きの観点で載せる。

>javac -version
javac 9-ea

実験

公式サイトのクイックスタートガイド

Project Jigsaw: Quick Start Guide

自分は、Greetings worldからはじめました。

Greetings world

やっていることは、org.astroっていうモジュールを作って外部公開し、それをcom.greetingsで利用しているだけ。

src/org.astro/module-info.java
src/org.astro/org/astro/World.java
src/com.greetings/com/greetings/Main.java
src/com.greetings/module-info.java

$ cat src/org.astro/module-info.java
module org.astro {
    exports org.astro;
}

$ cat src/org.astro/org/astro/World.java
package org.astro;
public class World {
    public static String name() {
        return "world";
    }
}

$ cat src/com.greetings/module-info.java
module com.greetings {
    requires org.astro;
}

$ cat src/com.greetings/com/greetings/Main.java
package com.greetings;
import org.astro.World;
public class Main {
    public static void main(String[] args) {
        System.out.format("Greetings %s!%n", World.name());
    }
}

一番注目するべきは、src/org.astro/module-info.javaと、src/com.greetings/module-info.javaの内容。
exportsで外部公開。requiresで依存関係を宣言している。
そして、module-info.java以外は、Java8以前のものと一緒。
覚えなければ行けないのは、module-info.javaだけみたい。

実行方法

出力先のディレクトリを作成

自分windowsでやってたので、意図を汲み取ってディレクトリを作成。たぶん、macなら下記コマンドでいけるハズ。

$ mkdir mods/org.astro mods/com.greetings

org.astroをコンパイル

$ javac -d mods/org.astro src/org.astro/module-info.java src/org.astro/org/astro/World.java

com.greetingsをコンパイル

注目すべきは、--module-pathでモジュールを含むディレクトリを宣言しているところ。
指定はしなくてもいいんだね。

$ javac --module-path mods -d mods/com.greetings src/com.greetings/module-info.java src/com.greetings/com/greetings/Main.jav

実行

java --module-path mods -m com.greetings/com.greetings.Main

感想

とりあえず、やりたきことは確認できた。
覚えなければならないことは、module-info.javaの記述方法と、コンパイル&実行方法だけみたいだね。
今回はサンプルのローカル確認で終了したが、次は自分で作ったソースでやれることを確認したい。

参考サイト

Project Jigsaw: Module System Quick-Start Guideをテキトーに訳した - kagamihogeの日記

JJUG CCC 2017 Spring 参加報告

http://www.java-users.jp/ccc2017spring/assets/img/jjug_logo.png

公式サイト

JJUG CCC 2017 Spring

受講内容

感想・メモ

感想とメモが混じっているので、読む時は注意 スピード重視で書いているので、内容や誤字脱字は大目に見てね!

jjug総会

メーリングリストからDoorkeperに移行。 会員数が多すぎるのと、スパムメールが増えてきたため。

最近のスパムメールは、苛立ちを覚えていた。
帰ったあと疑問に思ったが、メーリングリストはクローズされるんだよね?
残っていたら、スパムメールが飛び続けるのではなかろうかって思った。

非機能要件とSpring boot

speakerdeck.com

非機能要件とは

主目的以外の要件。性能やセキュリティ機能など。 機能横断要件でとらえるのもありとかも言ってた。
これはIPAの定義だろうか? どこから引用しているか見れんかった。

お客さんは、非機能要件がなんなのか分かりづらい。
その場に立ったことがないので、何とも言えんが。。。。
そんな場合は、IPAの非機能要求グレードを使うのが効果的らしい。
IPAが非機能要求グレードを出しているって初めて知った。
今回も合意のために利用しているようだ。

非機能要件にもいろろあるが、一部の要件は、フレームワークで対応することができる。それが、SpringSecurity & SpringBootActuratorなるものらしい。

Spring Boot Actuator

運用監視、活性保守をサポートする。 HTTP、JMXでアプリをモニタリング・管理できる。

インストールは、POIに依存性追加するだけ。

あとは、ブラウザでアクセスすればいい。 そうすると、JSONで結果が帰ってくる。

AuditEvents

認証認可イベント

health

アプリのミドルウェアの死活監視
独自の監視項目を追加することも可能

info

デフォルトではなにも表示されない
プロパティでinfo.があればそれを表示

git-commit-id-plugin

gitのバージョンを見れるようにしてくれる
gitバージョンを見れるのは良さそう
環境構築だけでなく、テストの障害報告とかにもバージョン情報はあると解析しやすいからね。

loggers

ログレベルの設定を確認できる。
特定のログレベルの確認もできる。
springbootでログレベルを変えられるので、効果が大きい。

metrics

cpu、メモリの情報が見れる exporterを実装するとredisなどにデータをエクスポートできる

trace

そのまま トレースログ見れる。

Spring security & other

パスワードポリシー

passay パスワードポリシーの作成ライブラリ

誤入力防止

terasolunaが提供している相関チェックアノテーションなるものがある。

ぶっちゃけ、Terasolunaって苦い経験しかなくて、あんまり使う気になれないのが、心情。

アカウントロック

spring fW @eventlistenerでイベントハンドリングする

データの秘匿

shaは辞めた方がいい。
sha系は速度優先のため、強度がそれほど高くない。
なので、ちょっと習熟すれば簡単に突破できるらしい。
passwordencoderを使うといいと勧めていた。

機密情報の暗号化

jasyptというライブラリを使って、暗号化すると楽らしい。
springboot-staterで提供されている

なお、シークレットキーはプロパティに入れないほうがいい。
入れたら暗号化の意味ないってのは、冷静にならないと分からなかったりする。

不正追跡・監視、トラッキングログ

サービスを跨いでも大丈夫なように、ユーザIDとリクエストごとに一意なトラッキングIDをもたせるのが一般的 横断的に追跡できる仕組みを用意しておくこと

Web対策

spring securityを使うことで、下記のことがデフォルトで対策される

  • セッション固定攻撃対策
  • xss対策(ただし、tymeleafを使った時)
  • csrf対策(同上)
  • セキュリティヘッダを自動で付けてくれる
    • キャッシュコントロール
    • https強制
    • コンテンツタイプの判定無効化

感想

springbootはアプリを簡易に作成できるだけのものだと思ったが、運用設計がやりやすい機能もあったのは意外だった。
SpringBootは、まだ知らない機能がいっぱいある。
使い始めが簡単なので、試してみる。 → TODO 特にセキュリティは、知らないとまるで意識しないので、重点的に確認する。

知らぬ間に立ち見がいっぱいおった。 何気ないところでゴキブリを見つけた気分だ。 それくらいびっくりしたわ。

terasoluna押しやった。
ntt系の会社とお仕事しているのかな?って思ったら、主要取引先にあった。
長年terasoluna使っているっぽいね。

エンプラ開発におけるレガシーアプリケーションの巻取りとモジュール分割の戦い

www.slideshare.net

現状

Struts1系。
変更履歴をコメントアウトで保持。
既存のアプリがあり、新規アプリを担当。
既存アプリとは別口のアプリを作成した。

新規アプリを作るときに決めたこと。

レガシーフレームワークを引き継がない 従来の開発文化を引き継がない

変化スイッチ

なんのことかよく分からんかった。
意識が変わったきっかけってことでOK?

終始、頭のなかで「やる気スイッチ」のCMが駆け巡っていたわ。

ブランチ運用

運用ルールが明確に定義されていない

バージョンごとの開発ブランチを作るような感じになっていて、masterへのマージは、リリース時

テスト自動化

エビデンス納品対象の制約があって、自動化にも制約がかかってしまった。
単体テスト → junitのソース納品
結合テスト → excelにハードコピーをペタペタ
結合は、seleniumのラッパーライブラリを使って効率化を図っている様子。
どこでもやってそう。

エビデンス納品を、単体レベルでも要求してくるところではなくてなくてよかったね!と言いたい。
単体レベルでも要求してくるところが、現実世界でもある。
※おとぎ話ではない!

辛いだけで、お客さんがそれを見てないと、何のために作ったのか分からんって思ってた。 実際、見てないしね。。。
恵まれているほうだと思う。

テストフェーズ

ここの開発でやっていたテストフェーズの概念

  • 単体
    機能確認。JUnitでテスト自動
  • 画面単体
    画面の機能確認。JUnitではテストしきれない機能を確認
  • 結合
    機能間の連携確認。Excelペタペタ

開発時の課題

テストケースのレビューが辛い。
JUnitのソースが見づらいと、網羅性が分からない。
レビュー者の負荷が高いので、レビューしやすいようにテストケースを作ることを心がけた。

現在の課題

ロジックに沿ったテストになってしまっている。 仕様に沿ったテストケースにしなければいけない。

テスト環境デプロイ

ローカルに落として デプロイが手作業で煩雑 並行開発だとテスト環境が足りない

pushするとビルドが走る。 デプロイする場合は、ビルドされたもの選択してデプロイしている

大人の事情

大人の事情により、既存アプリの保守も担当することに。
大人の事情だから、たぶん既存アプリの保守していたチームが、疲弊したか、障害多すぎてお客さんに愛想つかされたかのどっちかだろうね。

デプロイの話を聞いていたが、あり得ない状態だった。
本番warを解凍 → classファイル差し替え → 再圧縮 → デプロイ
最初のwarは、eclipseでビルドされたものらしい。
闇を見た気がする。
そうとうに業が深い。
お客さん側に、システム開発に精通した人が居なかったのだろうか?って感じた。

新規アプリで確立・成功したデプロイ方法になるように、既存状態を改修。
その過程は、省略だったのが惜しい!

モジュール分割

当初、ベンダー単位でモジュールを分割していた。そのせいで、できていないことが結構あった。
1社体制でのモジュール分割  マージ最小化  依存の最小化  モジュールごとの非機能要件

古いアプリを徐々に新しいアプリに移植
 → 新しいモノリシックなアプリを作っているだけでは?
確かにその通り。
結局のところ、APIで機能を作らないと、いくら刷新してもモノリシックな状態のものが出来上がるだけだと思っている。

変化

成功例がでないと、変化は起こしにくい印象

一括再構築

信頼関係のもと、段階的に再構築するしかない 世のトレンドをどうやって適用できるかを考えておかないと、説得ができない

チャンス

最後のチャンスを使う話は納得
チャンスは誰でも平等にくるけど、それを掴めるのは、準備している人だけ
だから、常日頃から、流行のトレンドをどうやって適用していけるか考えておかないと、変えるチャンスが来ても、逃してしまう。

感想

エビデンスの話は、言いたいことが結構ある。
まだ、恵まれている方だと思うが。。。
本当に辛いところは、単体レベルでもExcelペタペタを要求してくる。しかも、説明のコメント付きで。
SIerに多い印象がある。

チャンスの話は、ビジネス書みたいな感じだった。
日頃から準備してないと、チャンスが来ても逃げるってのは、納得。
ものにできないで終わるか、そもそも気づかないか。
常日頃から神経を研ぎすませていないとダメだと思う。

SpotBugs(FindBugs)による大規模ERPのコード品質改善

Java静的解析ツール機能・動向

checksyle

ソースコード解析をコンパイルなしで実行 コーディング規約の確認が主目的
OSSでは割りと使われている。 理由は、いろんな人が開発に携わるため。

PMD

ソースコード解析をコンパイルなしで実行 問題の発見が目的 CPD(コピペ検出)機能がある。

FindBugs

ソースコードではなく、バイトコード解析をする

SpotBugs

FindBugsの代価でデカくなってきた。

checker Framework

JSR308を利用する。 デファクト化しつつある。

Google error-prone

コンパイル時に動作 ソースコードの自動修正機能がある eclipseに非対応

Javaスキルの高い開発者がおおい

アノテーションの利用催促とspotbugs

Javaスキルにばらつきがある

checkstyleでコーディング規約を守るようにする

QA

Sonar lintがないのはなんで?
→ チェック内容の実態は、PMDとかFindBugsと変わらないので出さなかった。   複合的にルールを組み合わせるとこは素晴らしいと思っている。

コード品質が抱える問題と解決

開発している製品のアピールが長い! チェンナイってどこ?

デフォルト設定のまま使っていた

ビルドに時間がかかり、FindBugsを使うとパフォーマンス出ず、チェックをスキップする輩がいた。

きちんとやる/やらないを考えて適用を考える。

個人的にはデフォルト設定で運用して、変えてくでもいいと思っている。 明確な基準がある場合は、別だけど。

FindBugsが遅い

G1GC→回避できない
そもそも使うメモリが多ければ大丈夫だけど、それをするのは大変

他にも何か言っていた気がするが、ちょっと意識が飛んでた。。。。
たぶん、別の誰かが憑依したんだと思う。

文型さえおさえれば英語を読む力は上がる!

speakerdeck.com

ポイント

  • 辞書の意味を当てにするな
  • 文脈に頼りすぎない
  • 例外を気にしすぎない
  • 雰囲気で読まない

Google翻訳するなって言ってなかったからOKでいいよね。。?

5文型

というか、「文型」って書いて「ぶんけい」って読むことに驚いた。
てっきり誤字かと思ってたわ。。。

  • SV
  • SVC
  • SCO
  • SVOO

なんか、SVって言われると頭が痛い。。。
なんかの業務でSVってのが居た気がするが、なんだっけ?
商流系だった気がする。

文型については、意識したことない。

気をつけること

日本語の単語のまま使うのはダメ。
名刺っぽい単語でも、他動詞になるものがある。

introduction of project jigsaw

言っていることは信じないでくださいか。。。
jigsawがどうなるか分からないってことだろうか?
仕様承認の投票で、SE9は通ったけど、jigsawが通らないっていう謎の状態なのね。。。

red hat, ibmが反対
だから、信じないでくださいにつながるのか。

背景

いつものjar地獄とhadoopのクラスパス
Jigsawの話でココらへんのことを知らない人は居ないと思うので省略。

module

moduleかどうか判断する場合は、module-info.javaの存在有無を確認する。
ある→モジュールとして使う
ない→モジュールとして使わない

module-infoに書くもの

  • 依存関係
  • 公開範囲

module-info.javaの置き場

トップレベルに書く

module-ingoの内容

依存関係

requiresで指定する。

java.lang → 必ず使うので、記載しなくても依存に含まれていると思って良い。

publicは、exportしない限り、以前のpublicと同じではない。

モジュール化で公開有無が変わったため、Class.getInstanece()が使えなくなっている。

モジュール化したい場合

jdepsを使って、依存を見極める

jdepsについては、JavaDayTokyo2017のまとめにも出てきたので、よかったら見てみて

suzaku-tec.hatenadiary.jp

jreの自作

–genarate-module-info をjavacにつけると、独自のjreを作ってくれる

モジュールの扱い

自信はモジュールで、モジュールじゃないものを使う
automatic moduleを使う
安易なモジュール名になってしまうのが論点になっている。
automatic-module-nameを付けましょう的な流れになっているが、どうなるかは分からない。

QA

mavenとmoduleは、どうやって整合性をもたせるのか? → まだ決まってない

メタ情報なのにjavaなのはなんで?jsonじゃダメ → jsonbが入ればそうなるんじゃない?
javajson使うのは面倒くさいので、javaでいいんじゃない?

module化した場合としない場合の起動のち外 → そんなに変わらない。モジュール読む量によるかも。

moduleのバージョン → いまのところ掛けない

スーパーパッケージ → なくなった。

Java8コーディングベストプラクティス & NetBeansのメモリ仕様ログから機械学習できしだが働いているかどうか判定する

NetBeansのメモリ仕様ログから機械学習できしだが働いているかどうか判定する

jmxでデータを収集して、influxdbに突っ込み、grafanaで見る。

深層学習の話は、ある程度、知識としてあったので、なんとかついて行けた。
教師データは、たしかに教師データが正解だから、深層学習する意味ないよねってのは分かる。
深層学習を追い求めるロマンティストだったんだね。。。

Java8のプラクティス

基本的に、分かっているつもりの内容だったので、あんまり聞いてなかった。
たぶん、意識飛んでたと思う。

マチコ&河村の怒り新党 〜真の最終回〜

本家終わりましたからね。

初頭のトークは何を言っているかわからなかったが、内輪ネタかな?

場所を選ばないはずのITなのに東京開催の勉強会に腹が立つ

東京くれば? もしくは、自分で内輪で開催すればいいのではなかろうか?

実際に地方にいる人の意見だと、開催できない最大の要因は、金より人材な感じっぽい。
やっぱり数は力なんだね。

動画配信要因は、有志で募集中 勝手にやるのはNGなんで、声かけてね!

人いっぱいいるから、動画撮影好きのヤツはいる気がする。
それが山本さんだけなのかな?

CCCを地方開催するには、金の問題と人が集まるかが問題な気がする。
個人的には、関東でなければ、行かないと思う。

自分の上長の期限を伺うために、自分の部下に無茶振りする上司に腹が立つ。

そもそも昔からある。 企業文化として根付いている気がするので、このまま行けば仕事をしていれば出世できると思うよ?

周りに期待してもしょうがないから、転職すれば?って意見が最終だった

Javaの人は別の言語を勉強しろ!

この人はJavaしているのか不明の状態でスタート。。。

自分は、Python勉強中、Typescriptを業務で使用中。Javaは使ってないんだよね。。。
別の言語を勉強してもいいけど、Javaから多言語でも通用するような普遍的な知識を得られているから、結局他の言語勉強しなくてもいいかな?って思う。
一つの言語に習熟したら、他の言語もだいたい通用する。
現に、自分はTypescript知らなかったけど、全然問題なく使えているもの。

確かに、言語で何をしたいかが重要だね。
言語は手段であって、使えることが目的になると、ビジネスが成り立たなくなるような気がしないでもない。
「こういうこと言うからには、もちろんお前は複数言語を同じレベルで使えるんだよな?」って、喧嘩腰で聞きたくなる。

同僚が全く勉強しません

同じネタだね。。。

別にいいんじゃない?
自分が必要性を感じてないなら。
外部から働きかけても、内部からやる気を起こさないと、無意味だと思うんだよね。
その環境なら、転職するしかないね。 環境に不満を感じているなら。

勉強とは、周囲とのギャップを埋めるための勉強ってのは、納得の意見だ。 周囲が勉強しないことに不満を感じているなら、それは自己満足ってのも納得。 上司は、だいたい自己満足で勉強しろって言ってくるからな!

個人的には、周囲が勉強しないのは、むしろ好環境ではなかろうか?って思う。 だって、自分は勉強して優位に立てるんだから。 むしろお願いしたい。周囲の人に勉強しないでくださいって!
周囲との差別化も測れて、上司受けは好調にもなるしね!
ずっと自分の優位性が確保できる環境って素晴らしいと思うんですよ。

出た意見として、社内で少数でもいいから勉強する土台を作って、そこから徐々に変えて行くのがいいのではなかろうか?って意見もあった。

やった身の上からすると、だいたい付いて来ない。
上から圧力かけるかしない限りは、動かない。

老害が許せません

居場所を守るためにコミュニティを作ったり、昔の自慢話するのが許せない。

前回もあった気がする。
自分はぼっちなので、特に思うことはない。
一番気になるのは、電車で喋っている2人組で、上長っぽい人が自慢話が一番許せんと思うな。
なんか、スゲー偉そうにしていて、腹立たしく思うことが多々ある。
自社は、特に関係がないので、なんとも感じない。

我慢して時間が流れるのを待つしかないのか。。。? あれだ、電話かけてもらうアプリを使って、その場を切り抜けるってのが優良策かな?

新しいことにチャレンジしたいなら、老害を論破するしかない。
論破も、完膚なきまで。
そこまでできないなら、自分も害悪になっていると思うしかないね。

怒り心頭なこと

最後募集かけてたけど、人前でそういうこと話すのは、スゲー雰囲気悪くするから、名乗りでないと思うんだよね。。。

帰りの電車の中で思ったが、いくつかあったわ。

  1. 言っていることが矛盾しているPJリーダーに腹が立ちます。改善案を出せと言ってきたので、出したらみんなが聞いている前でディスる所業が始まりました。なんとか耐えましたが、その後、改善案を出す人は居ませんでした。このリーダーは本当に改善案を求めていたんでしょうか?
  2. 勉強しろという上長に腹が立ちます。上長は大して勉強していないくせに、配下メンバーには勉強を強いてくる。ここは、自分がやって言える立場になってからいうことだと思うのですが。。。
  3. 満員電車に腹が立ちます。満員状態で乗ろうとしたら、おっさんがDio並に「無理無理無理」って連呼してきました。乗るのを辞めたら、後ろから若い女性が乗り込もうとしました。その女性は乗れたのですが、その時は「無理」って言わないんだな。死ねばいいのに。
  4. 長いものに巻かれる上司に腹が立ちます。アーキテクチャの概念から、機能配置はこうあるべきと進言したのですが、上長で却下されました。理由を説明しましたが受け入れてもらえませんでした。その後、エンドユーザーのシステム開発のアーキテクトレベルの人が、まったく同じ指摘をしてきたら、その指摘は反映されました。なぜ?

あんまりシステム開発とかに関係ない気がする。。。

次回

かりそめになるのか。
かりそめ天国は、はっきり言ってつまらんからな。。。

ちょっと不安が募るわ。。。

Sli.doとか使って、匿名で意見もとめないと、発言しにくいんじゃなかろうかって感じる。
ただ、節度ある発言ができるかは疑問が残るけどね。。。

懇親会

LINE株式会社の寿司提供。
ありがたや~

寿司も、ワサビ付がデフォで良かった。
今のワサビ抜きの考えは間違っていると思うんですよ。

特に誰とも話すことなく、ある程度食して終了。
思ったけど、みんな顔赤すぎではなかろうか?
こんなに弱い人が多いんだなって感じた。

全体通しての感想

今回は、午前中(総会までかな?)は、人が全然いなかったのに、一気に増えた。
1000人もあのフロアでうごめいていたのかと思うと、驚愕。
全員倒したら、無双になれる!ってどうでもいいことを考えながら懇親会で食べてました。

あと、全員顔見知りなのだろうか?
自分、超小企業から来ているので、単独で参加している。
なんかみんな顔見知りみたいな感じで、ちょっといづらさは感じた。
いつもなら感じないんだけどね。流石に人が多すぎて、感じずにはいられなかった。

ToDo

  • Jigsawを試す
  • そろそろカンファレンスに登壇を考えてみる
  • Spot Bugsを試してみる
  • Google error-proneを試してみる
  • Spring Boot Actuatorを使ってみる
  • Spring Securityを使ってみる

関連リンク

前回のJJUG CCC

suzaku-tec.hatenadiary.jp

直近のJava記事

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp