読者です 読者をやめる 読者になる 読者になる

技術関連の覚書

案件でやったり自宅で試したことの覚書、自宅Redmineから移行

環境表示

こちらの記事を元に作って見ました。 環境設定がないとやはり再現できない原因がわからないなど困ることがありますね。

dev.classmethod.jp

検証環境

  • CPU Intel® Core™ i5-2500 CPU @ 3.30GHz
  • MEMORY 16318172 kB
  • DISTRIBUTION Ubuntu
  • RELEASE VER 16.04
  • CODE NAME xenial
  • KERNEL GNU/Linux

これだけだとただ書き写しただけなのでちょい足ししました。

  • 関数を使って2通りの出力内容にした

  • 出力オプションで-l:リスト形式、-t:テーブル形式で出力(getoptsを使用)

  • オプション違いはusageを出力

getoptsはbashのビルトインコマンドでコマンドライン引数を指定した変数に順次格納していくコマンドです。 書式は

getopts オプション文字の羅列 格納する変数

今回は-lと-tなのでオプション文字に「lt」と書きました。 値を設定するオプションの場合は:(コロン)を後ろにつけると変数OPTARGに値が保持されるので、値付きの場合はコロンをつけます。 例) -f table などとしたい場合 getopts f: OPT にすると、OPTにfが入った時に、OPTARGにtableが設定されます。

ファイル内容はこうなりました 当方Ubuntuなのでコマンドとかはちょっと変わります。

#!/bin/bash

# 環境取得
DIST_FILE="/etc/lsb-release"
MACHINE=$(uname -m)
CPU=$(grep "model name" /proc/cpuinfo|head -1)
MEM=$(grep "MemTotal" /proc/meminfo)
DISTRIB=$(grep DISTRIB_ID $DIST_FILE)
OS_VER=$(grep DISTRIB_RELEASE $DIST_FILE)
OS_NAME=$(grep DISTRIB_CODENAME $DIST_FILE)
KERNEL_VER=$(uname -o)

# MarkDown 形式で出力
# リスト形式
list() {
echo "- CPU ${CPU##*:}"
echo "- MEMORY ${MEM##*:}"
echo "- DISTRIBUTION ${DISTRIB#*=}"
echo "- RELEASE VER ${OS_VER#*=}"
echo "- CODE NAME ${OS_NAME#*=}"
echo "- KERNEL $KERNEL_VER"
}

# テーブル形式
table() {
echo "|カテゴリ|スペック|"
echo "|:-|:-|"
echo "|DISTRIBUTION|${DISTRIB#*=}|"
echo "|RELEASE VER|${OS_VER#*=}|"
echo "|CODE NAME|${OS_NAME#*=}|"
echo "|KERNEL|$KERNEL_VER|"
}

# usage
usage() {
   echo "usage:"
   echo "$0 [-l|-t]"
   echo "-l:list / -t:table"
}

if [ $# -ne 1 ]; then
   usage
   exit -1
fi

echo "#### 検証環境"
echo ""

while getopts lt OPT
do
    case $OPT in
    "l")
      list;;
    "t")
      table;;
    *)
      usage;;
    esac
done

-tの時の出力

検証環境

カテゴリ スペック
CPU Intel® Core™ i5-2500 CPU @ 3.30GHz
MEMORY 16318172 kB
DISTRIBUTION Ubuntu
RELEASE VER 16.04
CODE NAME xenial
KERNEL GNU/Linux

システム開発のアンチパターン

システム開発をする上でやってはいけないことがいくつかあると思う

開発過程での御法度

  • ファイルの紛失
  • デグレーション(先祖返り)

コーディングでの御法度

  • 同一処理の分散
  • 変更対応範囲の拡大

テストでの御法度

  • 未実施

しかし、これらはどこかしらで今も行われていると言う現実もある

その原因は

開発過程

ファイルの紛失
  • 共有ドライブでの管理での操作ミス

** 間違って消す、上書き、バックアップフォルダの間違い等で行方不明などによって引き起こされる これに関してはバージョン管理ツール(gitなど)でほぼ解決できる内容だが、使わない現場も多い 紛失等による修正コストと運用のための学習コストとの比較をすれば明らかに学習コストの方が低いはずと言うのが説得のポイントになる まずは、ファイルが無くなってもすぐに復旧できると言うところから説得していくしかなさそう

デグレーション(デグレ)

フォルダで管理しているが別々に作業していた人が誤って上書きする、古い物をバックアップから戻すなどで引き起こされる これもバージョン管理ツールで解決可能だが、これについては運用ルールも正しくないと同じ事が起こる 今まで見た中では、

  • 共有フォルダとバージョン管理ツールの平行運用 → 共有フォルダでの管理はどれが最新なのか、正しく日付等が管理されているかという問題で人的ミスが原因で起こる このデメリットをそのまま持ってきてしまってるので意味がない

  • コミットのタイミングがレビュー後でないとできない → 最終成果物しか管理されないため途中経過でのデグレの発生リスクはそのままとなり、デグレが発生しても最悪気づくのはレビュー時になる

  • ブランチの使用禁止(競合が発生するため) 上記コミットのタイミングのためブランチを使わない方針は少なくない

対策としては、競合しても簡単にマージできますアピールかな…

コーディング

コーディングでのアンチパターンは既に設計段階から始まります。

  • 共通化するもの、しないものの振り分け、処理パターンの洗い出しなどが不十分の場合

  • コーディング規約が曖昧な場合

  • そもそもアーキテクチャがおかしい場合

従来から行われている共通化の方法としては、共通関数を作る、それぞれの処理から呼び出すが一般的でした。 オブジェクト指向になって親クラスで共通処理をして、個別のメソッドは抽象クラスにして、それぞれの子で実装するが一般的になるでしょう。 DIを放り込んでおくなど、コーディング量を少なくすることが目的です。

しかし、中には昔ながらのコーディングが好きな人もいて、1ファイル1処理主義の方も未だに存在します(そろそろ絶滅したかな?)。 こういう人の説得が一番厄介ですが、根気よく共通化のメリットを説明しましょう。

共通関数呼び出しに行く人はまだ理解してくれることが多く、テンプレートパターンのように理解しやすいところから順序立てて説明していけば納得してくれることが多いようです。

ドキュメントとの整合性

設計書を書いてコードを書いて、誤りがあったらどちらを修正するかというと、どちらかというとコードから直す方が現実には多いです。 そのためドキュメントの修正が後回しになり、時には修正されずコードとの整合性が取られなくなることも多いです。 この際、ドキュメントを作らずRedmineのチケットなどで管理してドキュメント代わりにするところもあるようです。

しかし、まだドキュメントを作成するところの方が多いのは事実なのでこれは、なるべく忘れないうちにすぐに反映するしかないです。 そのためには、ドキュメントは極力簡略化することではないかと思います。 それから、コード一覧とか、画面項目一覧などは、一覧から画面HTMLの生成できるツールにするなど工夫することで作るメリットも生まれます。 ドキュメントを面倒な書き物にせずに便利なツールにすることでみんなが書きたくなる工夫も必要かな。

オンコード主義

接続情報の設定値や使用するSQLをソース上に記述するプロジェクトもありますが、これらはただの値であるためコンパイルは問題なく通ります。 しかし、それを検出するのは最悪テストの段階なのでそこまで検出できないことがよくあります。

設定値の場合は環境によって変わるものもあるのでソースを入れ換えなければならない場面も出てきます。 propertyファイルやxmlなどで管理しておくことで外部ファイルにできるのでそのようにしましょう。 環境で変化するものはgradleにちょっと書くだけで自動切り替えができます。 使ってない場合はそれぞれの環境用にファイルを用意してbuild.xmlMakefileにコピーを配置する記述を追加して切り替える方法もあります。

自動テストを使わない

画面の入力項目が多いものなどは動作確認だけでも入力に時間をとられます。 入力項目入れるべき値が正しいかという観点もあるので正しいテストを行うためにも自動化は必要です。 JUnitTestNGのようなメソッドを直接検査するツールとSeleniumような画面の動作を自動実行するツールがあるので用途に応じて使い分けましょう。 そして、テストは1度では終わらないということを管理者に認識してもらうことが導入許可への第一歩になります。

まとめ

システム開発は一人でするものではないため、設計書の書き方、コードの書き方、テストの方法などのルールを決めて行います。 そのため、規模が大きくなるほど、整合性を取ることが難しくなるためあまり、変わったことをせず従来どおりの方式を取ることが多くなります。 方式の決定は自分ではどうしようもないことも多いので、それに従うしかありませんが、ツールが無くてもバッチなどはテストプログラムを作成することもできます。

工数とのバランスを取りながら工夫していけると制約のある中でも効率をあげる方法はあると思います。

Ubuntu 17.4 Zesty Zapus 4/13リリース

ZestyZapus/ReleaseSchedule - Ubuntu Wiki

ZestyZapus/ReleaseNotes - Ubuntu Wiki

ここでベータ版が落とせます

今日はなにを書くか

ネタが出てこなかった

あるにはあるけどなんかつまらんなと言うのと、昔Swing使ってゲーム作った事とかだったっけど今さらSwingというのも

まだ、やろうとしていることは残ってるので

  • [ ] Zabbixのインストールとか
  • [ ] 中途半端に終わってるPostgresqlの続きとか
  • [ ] タスク管理の話とか
  • [] ブログでの数式の書き方とか

SQL最適化(3)

これ書いてなかったなというので追加

SORT CANCEL

例えばORDER BYで項目をソートする場合に、インデックスを使用するとインデックスの検索によってソートがかかるので、ORDER BYでのソートを取りやめて効率化します。

これがどういうときに有効利用できるかというと、LIMIT句で取得件数を制限する場合、ソートがかかっていれば必要な件数取得した時点で検索を終了します(LIMIT SCAN)。

SORT CANCELが働く場合と言うのは * SORT CANCEL BY INDEX 上で書いたとおりです

  • SORT CANCEL BY JOIN ORDER BYで指定している項目が結合条件に使用されている場合にORDER BYのソートをキャンセルします

  • SORT CANCEL BY DISTINCT ORDER BYで指定している項目がDISTINCT処理でソートされる場合にORDER BYのソートをキャンセルします

  • SORT CANCEL BY GROUPING ORDER BYに含まれる列がすべてグループ化処理によってソートされる場合にORDER BYのソート処理をキャンセルします

つまり、何かの処理でGROUP BYでソートしようとしていた項目に対するソートが働けば改めてソートをしないということです

SQL最適化実践編

このタイトルで書いてたんですが、操作ミスで下書き保存されてないままブラウザ落として消えてしまいました(泣)

今回はスマホからダイジェスト版で

実例で使うRDBMSはどれがいいか 商用製品 * OracleDatabase(無料のEnterprize版もある) * HiRDB(日立) * DB2(IBM) * SQLserver(Microsoft)

OSS * postgresql * mysql

実際の環境はdocker-composeで入れよう 1. qiitaから持ってくる 1. container_nameでエラー 1. 使えないらしいのでnameに変更 1. サービス名に記号が使えない 1. 変えてみて実行 1. dockerにゴミが残ってて実行できない 1. Postgres関連のコンテナをstop、kill、rm

こんな感じです 結論はDB設定まで行けてないというオチでした

追記

つなげなかった理由はこれです f:id:boctok-ctpoba:20170404215647p:plain

VMで放置しっ放しのpostgresqlが邪魔してました

相対性理論と機械学習

最近何かやらんといかんなと思って何がいいかなというので、そろそろ(ちょっと遅いかも)機械学習の事も知っておかないと思っていろいろと調べてみた(実際には今年の初めくらいからやってたりするのですが)

そうしたら、20年ぶりに再会した事があってちょっと驚いた

テンソルフロー(テンサーフロー,Tensor flow)というAIフレームワークの名前ですが、テンソルは運動量とか場の理論などで使われていて、学生時代にやった相対性理論でも使ってました

逆にカーナビ *1 でも作らない限りまた出会うこと無いかなと思っていた物に再会してちょっと感動

テンソル解析で求めた行列成分の偏微分は勾配の求め方とまったく同じ 空間の歪みと確率の分布が同じような概念で求められるんだなといったおもしろさを感じた

今日はこの辺で

この後、その数学的なつながりとかも書いていきたいな

当時読んでた相対性理論の本(もう中古しかないのか…) www.amazon.co.jp

当時読んでたテンソルの本 www.amazon.co.jp

Deep Learningの本(こちらでEbook Storeで電子版を購入すると安く手に入れられます) www.oreilly.co.jp

*1:カーナビは人工衛星からの電波を受信するため、人工衛星の時計と地上の時計の違いを相対論的なずれも計算しないと大幅にずれてしまいます