システム設計時の脱Excelの手助けとなるツール

これは何

業務で設計する際に、Excelを使わずにドキュメントを作成したいときに使いたいものまとめ。

Excelだと辛いこと

Excelで図を書こうとすると、図形の大きさや矢印の向き、吹き出しの位置の調整に結構時間を取られてしまう。 また、修正したときに差分確認がExcelだと出来ないのでどこを変えたのかがわかりにくい。

改善するにあたって重視するポイント

• 新たなツールを購入する必要が無い。
  • フリーのツールで実現できる。
• 導入が比較的容易である。
  • 環境構築するのが難しくない。
• テキストベースで資料を作成出来る。
  • テキストベースであるため、差分確認が容易である。
• 構文が難しくない
  • ある程度パターンを把握すれば、直感的に書くことが出来る。
• 図の配置はツールにほぼ一任が出来る。
  • 図によっては、ちょっと位置を変えたくなることがあるが、その時はオプションでちょっとだけどうにか出来る。
• 画像ファイルへエクスポートが出来る。
  • 書くのはテキストでも、画像に変換することで可視化が容易になる。

以降の記述に対する注意点

• 使うエディタは Visual Studio Code である。

code.visualstudio.com

• 書いた人はWindows10で使っている。
• テーブル設計で必要なER図は A5:SQL Mk-2 で作成しているので別扱いとした。

a5m2.mmatsubara.com

使っているツール

PlantUML

plantuml.com

• かなり有名なツールで、テキストで書きたいなと思って検索すると大抵はこれが上位に出てくる。
• 基本的な図はほぼこれ一本で書ける上、色々な図を書けるのでかなり重宝している。
• たまに公式サイトを見ると、新たな記法が追加されていることもあるので油断ならない。
• Visual Studio Codeにもプラグインが提供されているので、導入は難しくない。
  • プラグインの入れ方は「vscode plantuml」でググれば簡単に出てくるので、ここを見てとアナウンスが容易。

guiflow

もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita

qiita.com

uiflowのvscodeプラグインを作ってみました - Qiita

qiita.com

• PlantUMLよりは知名度は低いが、私が無知だっただけで実は結構使われているツールだった。
• PlantUMLだと書きにくい、画面遷移図もguiflowを使うと、テキストベースで書くことが出来る。
• 細かい画面項目を書くのではなく、ボタンを押したときやリンクをクリックしたときにどの画面に遷移するのかという資料を書くのにおすすめ。
• Visual Studio Codeにもプラグインが提供されているので、導入は難しくない。
  • プラグインの入れ方は2つ目のリンク先で紹介されている。

まとめ

細かい設計をする際にはまだどうしてもExcel仕様書になってしまうが（本来はこの辺りもテキスト主体で書けるとよいのだが…） 要件定義や大枠を決めて、必要な機能を洗い出す段階では上記、2ツールはかなり重宝する。

今関わっているシステム設計の要件定義では、私が使い始めたら周りも真似して使いだしたので差分管理が楽になった。 表現できる範囲の都合上、まだExcelで作成した図形の資料も残っているが、今まではExcelで作っていた資料が一部だけでもテキストベースになったことは大いなる進歩だと思う。

いずれは、各プログラムの詳細設計書も概要はMarkdownで書いて、細かい部分のみ用途に応じてPlantUMLだったり、guiflowだったり、ER図だったりでベースを作成し、画像エクスポートしたものを貼り付けていく形で開発が出来れば差分管理が容易になって最高なのでは？と想いを馳せている。

MethodHandleを試したメモ

これは何？

Twitterでこのツィートを見たので、どんなものなのかなと試した自分メモ

リフレクションは今後MethodHandleに置き換わっていくと思いますよ。リフレクションだとアクセスチェックが実行時に行われますが、MethodHandleだとMethodHandleの生成時にチェックできますし。 https://t.co/dalSnsmGg6

— Yuichi Sakuraba (@skrb) February 5, 2019

試したソース

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;

public class MethodHandlerTest {

    public static void main(String... args) {

        Object x, y; String s; int i;
        MethodType mt; MethodHandle mh;
        MethodHandles.Lookup lookup = MethodHandles.lookup();

        // mt is (char,char)String
        mt = MethodType.methodType(String.class, char.class, char.class);
        try {
//            mh = lookup.findVirtual(String.class, "replace", mt);
// 存在しないメソッドを書いたらどうなるか？⇒コンパイル時は検知してくれない
            mh = lookup.findVirtual(String.class, "aaa", mt);
            s = (String) mh.invokeExact("daddy",'d','n');

            System.out.println(s);

        } catch (NoSuchMethodException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        } catch (Throwable throwable) {
            throwable.printStackTrace();
        }


    }

}

docs.oracle.com に書かれている例をコピペしただけ。

試してみて

JavaのRumtime-Reflectionで厳しいの、後の改修で変更が入った時に静的な検出ができない点にあるので、MethodHandleに置き換わっても厳しさは変わらない印象ありますね。というかMethodHandle自体はリフレクションの手段の一つであってそれを動的に使うか静的に使うかは関知しなさそう https://t.co/rseoSDOmAW

— がくぞ (@gakuzzzz) February 5, 2019

ということだなと。 リフレクションよりはちょっとシンプルに書けそうだったけど、誰かが勝手にメソッド名を変えた時に動かすまで気づけないのは変わらないので ご利用は計画的に、は変わらない。

Oracleのパスワードが期限切れと出た時のメモ

「ORA-28001:パスワードが期限切れです」と出た時の対処法メモ

ググると出てくるのだけど、そのページがいつまでも残っているかわからないし、検索アルゴリズムの変更でたどり着けるかもわからないので自分用にメモっておく。

Oracleの管理アカウントでログインする。

sqlplus system/@@@@@@

管理アカウントのパスワードが分からなくなってしまったときはOracleが動いているサーバーからsysユーザーで入り、パスワードを再設定する。

sqlplus / as sysdba;

ALTER USER SYSTEM IDENTIFIED BY 新しいパスワード;

ALTER USER SYS IDENTIFIED BY 新しいパスワード;

デフォルトのプロファイルのパスワード有効期限を無期限にする。

ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;

エラーでログインできないユーザのパスワードを再設定する。

ALTER USER ユーザ名 IDENTIFIED BY 新パスワード;

ロックされているアカウントのロックを解除する。

ALTER USER ユーザ名 ACCOUNT UNLOCK;

以上。

”Javaが有償化される”という誤解を解くための資料

これは何？

Javaが有償化される！という誤解を解くために読むのをお勧めする雑誌だったりWeb記事のメモ。 この辺りを読めば、大部分の方の誤解は解けるのではないかな？と思っているが、さてはて…。

一覧

Software Design 2019年1月号

gihyo.jp

特集「リリースモデルの変更にどう対処する？Javaのバージョン問題に前向きに取り組む方法」を読むとよい。 好評だったようで雑誌現物はもう残っていないと見かけたが、電子版で購入は可能。

【GlassFish勉強会レポート】各JDKベンダの動向を知ってJava 11に備えよう

gihyo.jp

GlassFishユーザ会が2018年9月18日に開催した勉強会のレポート記事。各ベンダがどうするのか？がまとまっている。

2019年のJava

gihyo.jp

Javaチャンピオンの一人、寺田佳央氏の寄稿記事。日本のシステム開発の実情も踏まえた内容になっていてわかりやすい。

「Java is Still Free」――Javaのサポート問題へ終止符、迎える4つの進化【Oracle Code One 2018 Java Keynote】

codezine.jp

Oracle Code One 2018（2017年まではJavaOneだったイベント）の参加レポート。 イベントでどのようなお話があったかまとまっている。

Javaは今も無償です

docs.google.com

Javaコミュニティから出された声明、「Java Is Still Free」の日本語版。

なぜ「Javaが有償化する」と誤解されてしまうのか考えてみる

2019/2/1に追記。

kazokmr.hatenablog.com

Twitterで教えて頂いたはてなブログ記事。 今までの時系列を踏まえて、なぜ誤解してしまうのかについて述べられている。

JDK: 新しいリリースモデル解説

2019/4/23に追記。 Oracle伊藤さんが解説した時のスライド。

https://www.slideshare.net/oracle4engineer/jdk-ver-22-20190209

JDKの新しいリリース・モデルおよび提供ライセンスについて

2019/4/23に追記。 Oracle公式の資料を公開してなかったので追記する。

https://www.oracle.com/technetwork/jp/articles/java/ja-topics/jdk-release-model-4487660-ja.html

受託開発をやるときに考慮すべき環境面の事柄を色々

受託開発をやるときに、最初に考慮しておかないと後々大変そうな環境面を2018/12時点の心境でつらつらと。

バージョン管理

成果物全てのバージョン管理は何で行うべきか、と考えた時 バージョン管理はGitが今は主流だが、Subversionでも特に問題はないと考える。 その代り、Subversionのバージョンは最新にしておきたい。

Gitを使うなら、理想はGithubにお金を払ってprivateリポジトリでの作業だと思うが、 こんなこと書いている会社では厳しいと思うのでGitlabを開発環境のサーバーに入れるのが無難だろうと思う。

モック作成

ブラウザとJavaScript周りの制約が厳しくなっており、 htmlファイルをダブルクリックでただ開くだけでは見栄えが確認出来ない。

基本、Chromeベースで動作確認するのがよいが、お客様が実際に使っているブラウザを事前に確認しておくこと。

• html5ベースで作る。
• JavaScriptのライブラリは最新のものを使う。
• jQueryなど、ローカルファイルだと正常に起動しないことが増えたのでVSCodeのLive Serverを使うのもよさそう。
  • htmlファイルがあるフォルダを開いて、htmlを右クリックするとメニューに"Open with Live Server"が出てくるからクリックでサーバーが立ち上がる。
• ユーザーレビュー時は専用のサーバーを一時的に用意する？

開発

タスク管理

GitHubまたはGitlabのissue、Redmine、Backlog辺りが選択肢に入る。お客様と一緒に使うかどうかで変わってくる。 お客様にも書き込んでいただくのであればBacklogが無難かもしれない。

開発端末

いい端末を手配してもらう。

開発サーバー（データベースサーバー、APサーバーなど）

スペックは多少落ちてもやむを得ないので、OSは本番環境と出来るだけ合わせる。

負荷テストなどは実際のお客様の環境同等でないと行えないが、開発環境をそこまで整備できるか？というと厳しいと思われる。

Java

本番環境のOSに合わせる。

• お客様がOracleと契約するのであれば、Oracleを使う。
• RedHatならRedHat社のOpenJDK
• IBM系列ならAdoptOpenJDK with OpenJ9を使う
• それ以外ならAdoptOpenJDKでよさそう？

出来るだけ本番リリース時点の最新LTSバージョンを用いたいが（Java11、Java17、･･･） お客様の環境を最初に確認しておくこと。

載せるサーバーによっては既に動いているシステムがあってJavaのバージョンが変えられないかもしれない。

データベース

契約先が契約しているデータベースがあればそれを使う。 ライセンスを購入する必要が生じた場合は、お客様にライセンスを分けてもらうように交渉する。

何でもいい場合はMySQLかPostgreSQLかどちらかになると思うが、それぞれの違いをちゃんと見極めること。 本番リリース後に維持も引き続き行う場合は、本番のデータが全部入れられる容量のものを開発環境に入れること。

Webサーバー

無難なのはTomcatだと思うが、お客様の環境に合わせて検討する。

フレームワーク

現時点ではSpring Bootの一強だが、開発時点での状況を見極めて選択する。 他のプロジェクトでこれを使っていたから、とそのまま流用せずに見極めたい。

テスト

• Excelへのスクショ貼付けは出来るだけ減らしてJUnitを活用していく。
• 目視チェックしないと気づけない部分も多いので気を付ける。

開発ツール

• ビルドツールはMaven、またはGradleを使って使うライブラリの管理も含めて行う。
• 統合開発環境ツールはeclipseがどうしても標準になるが、統一はしなくてよいと思う。
  • eclipse、NetBeans、IntelliJ IDEA が候補になる。
• Jenkinsも導入しておきたい。

他に何があるかなぁ

エンジニアが情報収集とトレンドを追うのに読むと良いサイト

qiita.com

Twitterでしょ。 自分が使う言語でフォローする人を探していけば、あとはその人がはてぶだったり、引用RTだったりで有益な情報を教えてくれるよ。

プログラミングと執筆

プログラミング言語とあるのだからJavaもCOBOLもC言語も日本語や英語と同じ言語と言える。文法が違うだけ。

言語なので、プログラミングイコール執筆、または作文と同一なのではないか。

文章にするときは起承転結や全体の構成が大事。それはプログラミングでも同様で、まず処理全体の構成を考えて、それから内容を詰めていく。

変数名イコール文章内での言葉の使い方であり、適切な言葉を使うことでその文書全体の読みやすさ、伝わりやすさが変わってくる。

プログラマーイコールインタビュー、または編集者と考えられる。プログラミングは相手が伝えたいことを形にするもの、インタビュー記事は相手が伝えたいことを文章にするもの、出来上がるものは違うけどやりたいことは同じなのでは。

パッケージング&クラス名イコール索引であり、目的のところにたどり着くための手がかりである。適当にパッケージングして、適切なクラス名をつけると、書いている時は覚えているかもしれないが、後から読む人にとっては手掛かりがないので読めない。

コメントイコール注釈であり、仕様説明用のコメントイコール図解である。注釈が多い文書は読みにくいし、図解がない文書は読みにくい。

フォーマットイコール段落であり、段落がガタガタな文書は読みにくい。

一人で書くプログラミングでも、今プログラムを書いている時に読めていたコードが数日後の自分も読めるかは非常に怪しいものがある。

チーム開発は赤の他人が集まって行うものなので、他人が読みやすいものになっているかを充分に意識して書かないといけない。